הפעלת Windows Server Failover Clustering

אפשר ליצור אשכול יתירות כשל בעזרת Windows Server ב- Google Cloud. קבוצת שרתים פועלת יחד כדי לספק זמינות גבוהה (HA) לאפליקציות Windows שלכם. אם צומת אשכול אחד נכשל, צומת אחר יכול להשתלט על הפעלת התוכנה. אתם יכולים להגדיר שהמעבר לגיבוי יקרה באופן אוטומטי, וזו ההגדרה הרגילה, או להפעיל מעבר לגיבוי באופן ידני.

המדריך הזה מניח שאתם מכירים את הנושאים הבאים: אשכולות מעבר לגיבוי בעת כשל, Active Directory‏ (AD) וניהול של Windows Server.

סקירה קצרה על רשתות ב- Google Cloudזמינה במאמר Google Cloud למומחים במרכזי נתונים: רשתות.

ארכיטקטורה

במדריך הזה נסביר איך ליצור אשכול לדוגמה ליתירות כשל ב-Compute Engine. מערכת לדוגמה מכילה את שני השרתים הבאים:

  • מכונה וירטואלית ראשית של Compute Engine שמופעלת בה מערכת Windows Server 2016 באזור a.
  • מופע שני, שמוגדר כך שיתאים למופע הראשי באזור b.

בנוסף, אתם פורסים בקר דומיין של AD, שבתורו, לצורך המדריך הזה, משמש למטרות הבאות:

  • מספק דומיין של Windows.
  • הפונקציה פותרת שמות מארחים לכתובות IP.
  • מארח את העד לשיתוף קבצים שמשמש כ'קול' שלישי כדי להשיג את הקבוצה הנדרשת עבור האשכול.

אפשר ליצור את בקר הדומיין בכל אזור. במדריך הזה נעשה שימוש באזור c. במערכת ייצור, אפשר לארח את עדות שיתוף הקבצים במקום אחר, ולא צריך מערכת AD נפרדת רק כדי לתמוך באשכול הגיבוי האוטומטי. בקטע מה השלב הבא יש קישורים למאמרים על השימוש ב-AD ב- Google Cloud.

שני השרתים שבהם תשתמשו כדי לפרוס את אשכול יתירות הכשל נמצאים בתחומים שונים, כדי לוודא שכל שרת נמצא במכונה פיזית אחרת וכדי להגן מפני האפשרות הלא סבירה של כשל בתחום.

בתרשים הבא מתוארת הארכיטקטורה שפורסת באמצעות המדריך הזה.

תרשים ארכיטקטורה שמציג שתי מכונות וירטואליות ב-Compute Engine באשכול מעבר לגיבוי בעת כשל

אפשרויות של נפח אחסון משותף

ההדרכה הזו לא כוללת הסבר על הגדרת שרת קבצים לאחסון משותף עם זמינות גבוהה.

‫Google Cloud תומך בכמה פתרונות של אחסון משותף שאפשר להשתמש בהם עם Windows Server Failover Clustering, כולל:

למידע על פתרונות אפשריים אחרים לאחסון משותף, אפשר לעיין במאמרים הבאים:

הסבר על ניתוב ברשת

כשהאשכול עובר לגיבוי, הבקשות צריכות לעבור לצומת הפעיל החדש. בדרך כלל, טכנולוגיית האשכולות מטפלת בניתוב באמצעות פרוטוקול לפתרון כתובות (ARP), שמשייך כתובות IP לכתובות MAC. ב- Google Cloud, מערכת הענן הווירטואלי הפרטי (VPC) משתמשת ברשת מוגדרת באמצעות תוכנה, שלא מנצלת כתובות MAC. המשמעות היא שהשינויים שמועברים על ידי ARP לא משפיעים על הניתוב בכלל. כדי שהניתוב יפעל, האשכול צריך עזרה ברמת התוכנה מ-Internal Load Balancer.

בדרך כלל, איזון עומסים פנימי מפזר את תנועה ברשת הנכנסת בין כמה שרתי עורפיים פנימיים ב-VPC, כדי לחלק את העומס. במקום זאת, במקרה של אשכולות ליתירות כשל, משתמשים באיזון עומסים פנימי כדי לנתב את כל התנועה רק למכונה אחת: צומת האשכול הפעיל הנוכחי. כך איזון עומסים פנימי מזהה את הצומת הנכון:

  • כל מכונה וירטואלית מריצה מופע של סוכן Compute Engine שמספק תמיכה ב-Windows failover clustering. הסוכן עוקב אחרי כתובות ה-IP של המכונה הווירטואלית.
  • חזית מאזן העומסים מספקת את כתובת ה-IP לתעבורה הנכנסת לאפליקציה.
  • הקצה העורפי של מאזן העומסים מספק בדיקת תקינות. תהליך בדיקת תקינות שולח פינג לסוכן מעת לעת בכל צומת של אשכול באמצעות כתובת ה-IP הקבועה של מופע ה-VM דרך יציאה מסוימת. יציאת ברירת המחדל היא 59998.
  • בבדיקת תקינות נכללת כתובת ה-IP של האפליקציה כמטען ייעודי (payload) בבקשה.
  • הסוכן משווה את כתובת ה-IP בבקשה לרשימת כתובות ה-IP של מכונת ה-VM המארחת. אם הסוכן מוצא התאמה, הוא משיב עם הערך 1. אחרת, הפונקציה מחזירה 0.
  • מאזן העומסים מסמן כל מכונה וירטואלית שעוברת את בדיקת התקינות כתקינה. בכל רגע נתון, רק מכונה וירטואלית אחת עוברת את בדיקת התקינות כי רק למכונה וירטואלית אחת יש את כתובת ה-IP של עומס העבודה.

מה קורה במהלך מעבר לגיבוי (failover)

כאשר מתרחשת יתירות כשל באשכול, השינויים הבאים מתבצעים:

  • ב-Windows failover clustering, הסטטוס של הצומת הפעיל משתנה כדי לציין שהוא נכשל.
  • ב-Failover clustering, כל המשאבים והתפקידים באשכול מועברים מהצומת שנכשל לצומת הטוב ביותר, כפי שמוגדר על ידי הקוורום. הפעולה הזו כוללת העברה של כתובות ה-IP המשויכות.
  • בשיטת ה-Failover clustering, מנות ARP משודרות כדי להודיע לנתבי רשת מבוססי חומרה שכתובות ה-IP עברו. בתרחיש הזה, Google Cloud התקשורת ברשת מתעלמת מהחבילות האלה.
  • אחרי ההעברה, סוכן Compute Engine במכונה הווירטואלית של הצומת שנכשל משנה את התגובה שלו לבדיקת תקינות מ-1 ל-0, כי המכונה הווירטואלית כבר לא מארחת את כתובת ה-IP שצוינה בבקשה.
  • גם התגובה של סוכן Compute Engine במכונה הווירטואלית לבדיקת תקינות משתנה מ-0 ל-1.
  • מאזן העומסים הפנימי מפסיק לנתב את תעבורת הנתונים לצומת שנכשל, ומנתב אותה לצומת החדש שהופעל.

מחברים את הכול

אחרי שסקרתם כמה מהמושגים, הנה כמה פרטים שכדאי לשים לב אליהם בדיאגרמת הארכיטקטורה:

  • הסוכן של Compute Engine במכונה הווירטואלית ששמה wsfc-2 מגיב לבדיקת תקינות עם הערך 1, שמציין שזהו הצומת הפעיל באשכול. עבור wsfc-1, התשובה היא 0.
  • מאזן העומסים מנתב בקשות אל wsfc-2, כפי שמצוין על ידי החץ.
  • למאזן העומסים ול-wsfc-2 יש את כתובת ה-IP 10.0.0.9. במאזן העומסים, זו כתובת ה-IP שצוינה לקצה הקדמי. במקרה של מכונה וירטואלית, זו כתובת ה-IP של האפליקציה. אשכול הגיבוי האוטומטי מגדיר את כתובת ה-IP הזו בצומת הפעיל הנוכחי.
  • ל-failover cluster ול-wsfc-2 יש את כתובת ה-IP 10.0.0.8. למכונה הווירטואלית יש את כתובת ה-IP הזו כי היא מארחת כרגע את משאבי האשכול.

המלצות לשימוש במדריך הזה

במדריך הזה יש הרבה שלבים. לפעמים תתבקשו לפעול לפי השלבים שמפורטים במסמכים חיצוניים, כמו מסמכי העזרה של מיקרוסופט. חשוב לקרוא את ההערות במסמך הזה שמספקות פרטים ספציפיים לגבי השלבים החיצוניים.

במדריך הזה משתמשים ב-Cloud Shell במסוף Google Cloud . אפשר להשתמש בממשק המשתמש של מסוף Google Cloud או ב-CLI של gcloud כדי להגדיר אשכולות יתירות כשל, אבל במדריך הזה אנחנו משתמשים בעיקר ב-Cloud Shell כדי להקל עליכם. הגישה הזו עוזרת לכם להשלים את ההדרכה מהר יותר. במקרים מסוימים, השלבים מתבצעים במסוף Google Cloud .

Cloud Shell

מומלץ ליצור תמונות מצב של הדיסקים לאחסון מתמיד ב-Compute Engine במהלך התהליך. אם משהו משתבש, אפשר להשתמש בתמונת מצב כדי לא להתחיל מחדש. במדריך הזה מוצעות שעות טובות לצילום התמונות.

אם אתם מגלים שהדברים לא פועלים כמו שציפיתם, יכול להיות שיש הוראות בקטע שאתם קוראים. אחרת, אפשר לעיין בקטע פתרון בעיות.

מטרות

  • יוצרים רשת.
  • התקנת Windows Server 2016 בשתי מכונות וירטואליות של Compute Engine.
  • מתקינים ומגדירים את Active Directory במופע שלישי של Windows Server.
  • מגדירים את אשכול הגיבוי, כולל עדות לשיתוף קבצים לקוורום ותפקיד לעומס העבודה.
  • מגדירים את מאזן העומסים הפנימי.
  • בודקים את פעולת היתירות כשל כדי לוודא שהאשכול פועל.

עלויות

במדריך הזה נעשה שימוש בתמונות של Compute Engine שכוללות רישיונות של Windows Server. המשמעות היא שהעלות של הפעלת המדריך הזה יכולה להיות משמעותית אם משאירים מכונות וירטואליות פועלות. מומלץ להפסיק את השימוש במכונות הווירטואליות כשלא משתמשים בהן.

כדי לקבל הערכה של העלויות להשלמת המדריך הזה, אפשר להיעזר במחשבון התמחור.

לפני שמתחילים

  1. נכנסים לחשבון Google Cloud . אנחנו ממליצים למשתמשים חדשים ב- Google Cloud ליצור חשבון כדי שיוכלו להעריך את הביצועים של המוצרים שלנו בתרחישים מהעולם האמיתי. לקוחות חדשים מקבלים בחינם גם קרדיט בשווי 300$ להרצה, לבדיקה ולפריסה של עומסי העבודה.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  3. Verify that billing is enabled for your Google Cloud project.

  4. Enable the Compute Engine API, if it is not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the API

  5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Roles required to select or create a project

    • Select a project: Selecting a project doesn't require a specific IAM role—you can select any project that you've been granted a role on.
    • Create a project: To create a project, you need the Project Creator role (roles/resourcemanager.projectCreator), which contains the resourcemanager.projects.create permission. Learn how to grant roles.

    Go to project selector

  6. Verify that billing is enabled for your Google Cloud project.

  7. Enable the Compute Engine API, if it is not already enabled.

    Roles required to enable APIs

    To enable APIs, you need the serviceusage.services.enable permission. If you created the project, then you likely already have this permission through the Owner role (roles/owner). Otherwise, you can get this permission through the Service Usage Admin role (roles/serviceusage.serviceUsageAdmin). Learn how to grant roles.

    Enable the API

    8.
  8. מפעילים מופע של Cloud Shell.
    כניסה ל-Cloud Shell

יצירת הרשת

האשכול שלכם דורש רשת בהתאמה אישית. משתמשים ב-VPC כדי ליצור רשת בהתאמה אישית ותת-רשת אחת על ידי הפעלת פקודות gcloud ב-Cloud Shell.

  1. יוצרים את הרשת:

    gcloud compute networks create wsfcnet --subnet-mode custom

    שם הרשת שיצרתם הוא wsfcnet.

  2. יוצרים רשת משנה. מחליפים את [YOUR_REGION] באזור Google Cloud קרוב:

    gcloud compute networks subnets create wsfcnetsub1 --network wsfcnet --region [YOUR_REGION] --range 10.0.0.0/16

    השם של רשת המשנה שיצרתם הוא wsfcnetsub1.

שימו לב שטווח CIDR של כתובות ה-IP ברשת המשנה הזו הוא 10.0.0.0/16. זוהי דוגמה לטווח שמשמש במדריך הזה. במערכות ייצור, כדאי לעבוד עם אדמינים של הרשת כדי להקצות טווחים מתאימים לכתובות IP של המערכות.

יצירת כללים לחומת האש

כברירת מחדל, הרשת שלכם סגורה לתעבורה חיצונית. כדי לאפשר חיבורים מרוחקים לשרתים, צריך לפתוח יציאות בחומת האש. משתמשים בפקודות gcloud ב-Cloud Shell כדי ליצור את הכללים.

  1. במדריך הזה, פותחים את יציאה 3389 ברשת הראשית כדי לאפשר חיבורי RDP. בפקודה הבאה, מחליפים את [YOUR_IPv4_ADDRESS] בכתובת ה-IP של המחשב שבו משתמשים כדי להתחבר למכונות הווירטואליות. במערכת ייצור, אפשר לספק טווח כתובות IP או סדרה של כתובות.

    gcloud compute firewall-rules create allow-rdp --network wsfcnet --allow tcp:3389 --source-ranges [YOUR_IPv4_ADDRESS]

  2. ברשת המשנה, מאפשרים את כל הפרוטוקולים בכל היציאות כדי שהשרתים יוכלו לתקשר ביניהם. במערכות ייצור, מומלץ לפתוח רק יציאות ספציפיות, לפי הצורך.

    gcloud compute firewall-rules create allow-all-subnet --network wsfcnet --allow all --source-ranges 10.0.0.0/16

    שימו לב שהערך source-ranges תואם לטווח ה-CIDR שבו השתמשתם כדי ליצור את רשת המשנה.

  3. צפייה בכללים של חומת האש:

    gcloud compute firewall-rules list

    הפלט אמור להיראות כך:

    NAME              NETWORK  DIRECTION  PRIORITY  ALLOW            DENY  DISABLED
allow-all-subnet  wsfcnet  INGRESS    1000      all                    False
allow-rdp         wsfcnet  INGRESS    1000      tcp:3389               False

הפעלת אשכולות למעבר אוטומטי לגיבוי ב-Compute Engine

כדי להפעיל אשכולות למעבר אוטומטי לגיבוי בסוכן Compute Engine, צריך להוסיף את הדגל enable-wsfc=true להגדרות של המכונה הווירטואלית. אפשר לעשות את זה על ידי ציון הדגל כמטא-נתונים מותאמים אישית של המכונה הווירטואלית, או על ידי יצירת קובץ הגדרה בכל מכונה וירטואלית, כמו שמתואר במסמכי Compute Engine.

במדריך הזה מוגדר הדגל כמטא-נתונים בהתאמה אישית כשיוצרים את המכונות הווירטואליות, כפי שמתואר בקטע הבא. בנוסף, ההדרכה מסתמכת על התנהגות ברירת המחדל של wsfc-addrs ו-wsfc-agent-port, כך שלא צריך להגדיר את הערכים האלה.

יצירת השרתים

לאחר מכן, יוצרים את 3 השרתים. משתמשים בפקודה gcloud ב-Cloud Shell.

יצירת השרת הראשון של צומת באשכול

יוצרים מכונה חדשה של Compute Engine. מגדירים את המכונה באופן הבא:

  • נותנים למכונה את השם wsfc-1.
  • מגדירים את הדגל --zone לאזור שנוח לכם. לדוגמה, us-central1-a.
  • מגדירים את הדגל --machine-type לערך n1-standard-2..
  • מגדירים את הדגל --image-project לערך windows-cloud.
  • מגדירים את הדגל --image-family לערך windows-2016.
  • מגדירים את הדגל --scopes לערך https://www.googleapis.com/auth/compute.
  • מגדירים את הדגל --can-ip-forward כדי להפעיל העברת IP.
  • מגדירים את הדגל --private-network-ip לערך 10.0.0.4.
  • מגדירים את הרשת ל-wsfcnet ואת רשת המשנה ל-wsfcnetsub1.
  • משתמשים בפרמטר --metadata כדי להגדיר את enable-wsfc=true.

מריצים את הפקודה הבאה ומחליפים את [YOUR_ZONE_1] בשם של האזור הראשון:

gcloud compute instances create wsfc-1 --zone [YOUR_ZONE_1] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.4 --network wsfcnet --subnet wsfcnetsub1 --metadata enable-wsfc=true

יצירת השרת השני של צומת האשכול

בשרת השני, מבצעים את אותם השלבים, אבל:

  • מגדירים את שם המכונה לערך wsfc-2.
  • מגדירים את הדגל --zone לאזור אחר מזה שבו השתמשתם עבור השרת הראשון. לדוגמה, us-central1-b.
  • מגדירים את הדגל --private-network-ip לערך 10.0.0.5.

מחליפים את [YOUR_ZONE_2] בשם האזור השני:

gcloud compute instances create wsfc-2 --zone [YOUR_ZONE_2] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.5 --network wsfcnet --subnet wsfcnetsub1  --metadata enable-wsfc=true

יצירת השרת השלישי ל-Active Directory

במקרה של בקר הדומיין, פועלים לפי אותם השלבים, אבל:

  • מגדירים את שם המכונה לערך wsfc-dc.
  • מגדירים את הדגל --zone לאזור שונה מהאזורים שבהם השתמשתם עבור השרתים האחרים. לדוגמה, us-central1-c.
  • מגדירים את הדגל --private-network-ip לערך 10.0.0.6.
  • השמטה של --metadata enable-wsfc=true.

מחליפים את [YOUR_ZONE_3] בשם האזור:

gcloud compute instances create wsfc-dc --zone [YOUR_ZONE_3] --machine-type n1-standard-2 --image-project windows-cloud --image-family windows-2016 --scopes https://www.googleapis.com/auth/compute --can-ip-forward --private-network-ip 10.0.0.6 --network wsfcnet --subnet wsfcnetsub1

הצגת המקרים

אפשר לראות את הפרטים של המכונות שיצרתם.

gcloud compute instances list

הפלט אמור להיראות כך:

NAME     ZONE           MACHINE_TYPE  PREEMPTIBLE INTERNAL_IP  EXTERNAL_IP     STATUS
wsfc-1   us-central1-a  n1-standard-2             10.0.0.4     35.203.131.133  RUNNING
wsfc-2   us-central1-b  n1-standard-2             10.0.0.5     35.203.130.194  RUNNING
wsfc-dc  us-central1-c  n1-standard-2             10.0.0.6     35.197.27.2     RUNNING

התחברות למכונות ה-VM

כדי להתחבר ל-VM מבוסס Windows, קודם צריך ליצור סיסמה ל-VM. אחרי זה תוכלו להתחבר למכונה הווירטואלית באמצעות RDP.

יצירת סיסמאות

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. לוחצים על השם של המכונה הווירטואלית שרוצים להגדיר לה סיסמה חדשה.

  3. בדף פרטי המופע, לוחצים על הלחצן Set Windows Password (הגדרת סיסמה ל-Windows). סיסמה נוצרת בשבילכם. מעתיקים את הסיסמה ושומרים אותה במקום מאובטח.

חיבור באמצעות RDP

במאמרי העזרה של Compute Engine מוסבר איך להתחבר למכונות וירטואליות של Windows באמצעות RDP. אתם יכולים:

  • משתמשים בלקוח קיים.
  • מוסיפים לדפדפן תוסף Chrome RDP ואז מתחברים דרך מסוףGoogle Cloud .

בכל פעם שמצוין במדריך הזה להתחבר למופע של Windows, צריך להשתמש בחיבור RDP המועדף.

הגדרת רשתות ב-Windows

כתובות ה-IP הפנימיות שהקציתם כשנוצרו המכונות הווירטואליות הן סטטיות. כדי לוודא שמערכת Windows מתייחסת לכתובות ה-IP כאל כתובות סטטיות, צריך להוסיף אותן, יחד עם כתובות ה-IP של שער ברירת המחדל ושרת ה-DNS, להגדרת הרשת של Windows Server.

משתמשים ב-RDP כדי להתחבר אל wsfc-1, wsfc-2 ו-wsfc-dc, וחוזרים על השלבים הבאים לכל מופע:

  1. ב-Server Manager, בחלונית הימנית, בוחרים באפשרות Local Server (שרת מקומי).
  2. בקטע Ethernet בחלונית Properties, לוחצים על IPv4 address assigned by DHCP, IPv6 enabled.
  3. לוחצים לחיצה ימנית על Ethernet (אתרנט) ובוחרים באפשרות Properties (מאפיינים).
  4. לוחצים פעמיים על Internet Protocol Version 4 (TCP/IPv4)‎.
  5. בוחרים באפשרות Use the following IP address (שימוש בכתובת ה-IP הבאה).

  6. מזינים את כתובת ה-IP הפנימית שהקציתם למכונה הווירטואלית כשנוצרה.

    • בשדה wsfc-1, מזינים '10.0.0.4'.
    • בשדה wsfc-2 מזינים '10.0.0.5'.
    • בשדה wsfc-dc מזינים '10.0.0.6'.

  7. בשדה מסכה של רשת משנה, מזינים '255.255.0.0'.

  8. בשדה Default gateway, מזינים את 10.0.0.1, כתובת ה-IP שהוזמנה אוטומטית לשער ברירת המחדל כשיוצרים את תת-הרשת wsfcnetsub1.

    כתובת ה-IP של שער ברירת המחדל היא תמיד הכתובת השנייה בטווח ה-IP הראשי של רשת משנה. כתובות שלא ניתן להשתמש בהן בטווחים של רשתות משנה ב-IPv4

  9. ל-wsfc-1 ו-wsfc-2 בלבד:

    1. לוחצים על שימוש בכתובות שרתי ה-DNS הבאות.

    2. בקטע Preferred DNS server (שרת DNS מועדף), מזינים '10.0.0.6'.

  10. סוגרים את כל תיבות הדו-שיח.

    החיבור דרך RDP יאבד כי השינויים האלה מאפסים את מתאם הרשת הווירטואלית של המכונה הווירטואלית.

  11. סוגרים את סשן ה-RDP ומתחברים מחדש למופע. אם תיבת הדו-שיח מהשלב הקודם עדיין פתוחה, סוגרים אותה.

  12. בקטע המאפיינים של השרת המקומי, מוודאים שההגדרה Ethernet משקפת את כתובת ה-IP של השרת המקומי (10.0.0.4,‏ 10.0.0.5,‏ או 10.0.0.6). אם לא, פותחים מחדש את תיבת הדו-שיח Internet Protocol Version 4 (TCP/IPv4) ומעדכנים את ההגדרה.

זה זמן טוב לצלם תמונות מצב של wsfc-1 ושל wsfc-2.

הגדרת Active Directory

עכשיו מגדירים את בקר הדומיין.

  1. משתמשים ב-RDP כדי להתחבר לשרת שנקרא wsfc-dc.
  2. באמצעות אפליקציית שולחן העבודה 'ניהול המחשב' של Windows, מגדירים סיסמה לחשבון האדמין המקומי.
  3. מפעילים את חשבון האדמין המקומי.

  4. כדי להגדיר את בקר הדומיין, פועלים לפי השלבים בהוראות של מיקרוסופט שבהמשך, עם ההערות הנוספות האלה. אפשר להשתמש בערכי ברירת מחדל ברוב ההגדרות.

    • מסמנים את תיבת הסימון של התפקיד DNS Server (שרת DNS). השלב הזה לא מפורט בהוראות.
    • מסמנים את תיבת הסימון Restart the destination server automatically if required (הפעלה מחדש אוטומטית של שרת היעד אם נדרש).
    • מקדמים את שרת הקבצים לבקר דומיין.
    • במהלך השלב Add a new forest (הוספת יער חדש), נותנים לדומיין את השם WSFC.TEST.
    • מגדירים את שם הדומיין של NetBIOS כ-WSFC (ברירת המחדל).

    הוראות של מיקרוסופט

זה זמן טוב לצלם תמונה של wsfc-dc.

יצירת חשבון משתמש בדומיין

יכול להיות שיעבור קצת זמן עד ש-wsfc-dc יופעל מחדש. לפני שמצטרפים לשרתים בדומיין, משתמשים ב-RDP כדי להיכנס ל-wsfc-dc ולוודא שבקר הדומיין פועל.

צריך משתמש בדומיין עם הרשאות אדמין בשרתים של האשכול. איך לעשות את זה?

  1. בבקר הדומיין (wsfc-dc) לוחצים על התחל, ואז מקלידים dsa כדי למצוא ולפתוח את האפליקציה 'משתמשים ומחשבים ב-Active Directory'.
  2. לוחצים לחיצה ימנית על WSFC.TEST, מצביעים על New (חדש) ואז לוחצים על User (משתמש).
  3. בשדות Full name (שם מלא) ו-User logon name (שם הכניסה של המשתמש), מזינים cluster-admin.
  4. לוחצים על הבא.
  5. מזינים סיסמה למשתמש ומאשרים אותה. בוחרים את אפשרויות הסיסמה בתיבת הדו-שיח. לדוגמה, אפשר להגדיר שהסיסמה לא תפוג לעולם.
  6. מאשרים את ההגדרות ולוחצים על סיום.

  7. הגדרת cluster-admin כאדמין ב-wsfc-dc:

    • לוחצים לחיצה ימנית על cluster-admin ובוחרים באפשרות הוספה לקבוצה.
    • מקלידים Administrators (אדמינים) ולוחצים על OK (אישור).

במדריך הזה נעשה שימוש בחשבון WSFC.TEST\cluster-admin כחשבון אדמין בכל מקום שבו נדרש חשבון כזה. במערכת ייצור, צריך לפעול לפי שיטות האבטחה הרגילות שלכם להקצאת חשבונות והרשאות. מידע נוסף זמין במאמר סקירה כללית על חשבונות Active Directory שנדרשים לאשכול מעבר לגיבוי בעת כשל.

הצטרפות השרתים לדומיין

מוסיפים את שני השרתים של צומתי האשכול לדומיין WSFC.TEST. מבצעים את השלבים הבאים בכל שרת של צומת באשכול (wsfc-1 ו-wsfc-2):

  1. ב-Server Manager (ניהול שרתים) > Local Server (שרת מקומי), בחלונית Properties (מאפיינים), לוחצים על WORKGROUP (קבוצת עבודה).
  2. לוחצים על Change.
  3. בוחרים באפשרות דומיין ומזינים את הערך WSFC.TEST.
  4. לוחצים על OK.
  5. מזינים את פרטי הכניסה של WSFC.TEST\cluster-admin כדי להצטרף לדומיין.
  6. לוחצים על OK.
  7. סוגרים את תיבות הדו-שיח ופועלים לפי ההנחיות להפעלה מחדש של השרת.

  8. ב-Server Manager (ניהול השרת), מגדירים את cluster-admin כאדמין ב-wsfc-1 וב-wsfc-2. אפשר גם לנהל הרשאות אדמין באמצעות מדיניות קבוצתית.

    • בתפריט כלים, בוחרים באפשרות ניהול המחשב > משתמשים וקבוצות מקומיים > קבוצות > אדמינים, ואז לוחצים על הוספה.
    • מזינים cluster-admin ולוחצים על בדיקת שמות.
    • לוחצים על OK.

בשלב הזה מומלץ לצלם תמונות מצב של כל שלוש המכונות הווירטואליות.

הגדרת אשכולות למעבר אוטומטי לגיבוי (failover)

שמירת כתובת IP לאשכול ב-Compute Engine

כשיוצרים את אשכול הגיבוי, מקצים כתובת IP כדי ליצור נקודת גישה לניהול. בסביבת ייצור, יכול להיות שתשתמשו בכתובת IP מרשת משנה נפרדת. עם זאת, במדריך הזה נשמור כתובת IP מתת-הרשת שכבר יצרתם. שמירת כתובת ה-IP מונעת התנגשויות עם הקצאות אחרות של כתובות IP.

  1. פותחים טרמינל במכונת VM מארחת או פותחים את Cloud Shell.

    כניסה ל-Cloud Shell

  2. שמירת כתובת IP. במדריך הזה נשתמש ב-10.0.0.8:

    gcloud compute addresses create cluster-access-point --region [YOUR_REGION] --subnet wsfcnetsub1 --addresses 10.0.0.8

  3. כדי לאשר את שמירת כתובת ה-IP:

    gcloud compute addresses list

יצירת האשכול

כדי ליצור ולהגדיר את אשכול הגיבוי:

  1. משתמשים ב-RDP כדי להתחבר אל wsfc-1 ואל wsfc-2.

  2. פועלים לפי השלבים בהוראות של מיקרוסופט שבהמשך, עם ההערות הנוספות האלה:

    • מתקינים את התכונה Failover Clustering ב-wsfc-1 וב-wsfc-2. אל תתקינו את התכונה Failover Clustering ב-wsfc-dc.
    • מפעילים את האפליקציה Failover Cluster Manager כמשתמש בדומיין WSFC.TEST\cluster-admin. אחרת, יכול להיות שתיתקלו בבעיות בהרשאות. מומלץ להריץ את Failover Cluster Manager תמיד בדרך הזו, או להתחבר לשרת בתור cluster-admin כדי לוודא שיש לכם את ההרשאות הנדרשות.
    • מוסיפים את wsfc-1 ואת wsfc-2 לאשכול כצמתים.

    • כשמאמתים את ההגדרות:

      • בדף אפשרויות בדיקה, בוחרים באפשרות הפעלת בדיקות רק של הפריטים שאבחר ואז לוחצים על הבא.

      • בדף Test Selection (בחירת בדיקה), מבטלים את הסימון של Storage (אחסון) כי האפשרות Storage תיכשל אם היא תופעל ב-Compute Engine (כמו שהיא תיכשל אם היא תופעל בשרתים פיזיים נפרדים ועצמאיים).

        בעיות נפוצות שאפשר להיתקל בהן במהלך אימות האשכול:

        • ממשק רשת אחד בלבד בין העותקים. אפשר להתעלם מההודעה הזו כי היא לא רלוונטית להגדרה מבוססת-ענן.
        • העדכונים של Windows לא זהים בשתי הרפליקות. אם הגדרתם את מופעי Windows כך שיחילו עדכונים באופן אוטומטי, יכול להיות שאחד מהצמתים החיל עדכונים שהצומת השני עדיין לא הוריד. מומלץ להגדיר את השרתים בצורה זהה.
        • הפעלה מחדש בהמתנה. ביצעת שינויים באחד השרתים, וצריך להפעיל אותו מחדש כדי שהשינויים יחולו. אל תתעלמו מההודעה הזו.
        • לשרתים לא מוגדר אותו תפקיד בדומיין. אפשר להתעלם מההודעה הזו.
        • השרתים לא נמצאים באותה יחידה ארגונית (OU). במדריך הזה לא נעשה שימוש ביחידה ארגונית, אבל במערכת ייצור כדאי להוסיף את האשכול ליחידה ארגונית משלו. ההוראות של מיקרוסופט מתארות את השיטה המומלצת הזו.
        • נמצאו מנהלי התקנים לא חתומים. אפשר להתעלם מההודעה הזו.

    • בדף סיכום, אפשר ללחוץ על יצירת האשכול עכשיו באמצעות הצמתים שאומתו כדי להמשיך ליצירת האשכול, במקום לסגור את האשף ולפתוח אותו מחדש.

    • באשף ליצירת אשכול, בדף נקודת גישה:

      • נותנים לאשכול את השם testcluster.
      • בשדה כתובת, מזינים את כתובת ה-IP ששמרתם קודם, 10.0.0.8.

    הוראות של מיקרוסופט

הוספת אדמין לאשכול

הוספת חשבון דומיין כאדמין באשכול מאפשרת לכם לבצע פעולות באשכול באמצעות כלים כמו Windows PowerShell. מוסיפים את חשבון הדומיין cluster-admin כאדמין של האשכול.

  1. בצומת של האשכול שמארח את משאבי האשכול, ב-Failover Cluster Manager, בוחרים את האשכול בחלונית הימנית ואז לוחצים על Properties (מאפיינים) בחלונית השמאלית.
  2. לוחצים על הכרטיסייה Cluster Permissions (הרשאות אשכול).
  3. לוחצים על הוספה ואז מוסיפים את cluster-admin.
  4. כשבוחרים באפשרות cluster-admin ברשימת השמות של קבוצות או משתמשים, בוחרים באפשרות שליטה מלאה בחלונית הרשאות.
  5. לוחצים על אישור ואז על החלה.

זה זמן טוב ליצור תמונות מצב.

יצירת העד לשיתוף הקבצים

יש לכם אשכול לגיבוי בעל שני צמתים, אבל האשכול משתמש במנגנון הצבעה כדי להחליט איזה צומת צריך להיות פעיל. כדי להגיע לקוורום, אפשר להוסיף עדות לשיתוף קבצים.

במדריך הזה מוסיפים תיקייה משותפת לשרת בקר הדומיין. אם השרת הזה יצא משימוש בזמן שאחד מצמתי האשכול מופעל מחדש, יכול להיות שהאשכול כולו יפסיק לפעול כי השרת שנותר לא יכול להצביע בעצמו. במדריך הזה אנחנו מניחים שתכונות התשתית, Google Cloudכמו העברה פעילה והפעלה מחדש אוטומטית, מספקות אמינות מספקת כדי שהתיקייה המשותפת תישאר פעילה.

אם רוצים ליצור עדות לשיתוף קבצים עם זמינות גבוהה יותר, אפשר לבחור באחת מהאפשרויות הבאות:

  • משתמשים באוסף של שרתי Windows כדי לספק את השיתוף באמצעות Storage Spaces Direct. התכונה הזו ב-Windows Server 2016 יכולה לספק שיתוף עם זמינות גבוהה לעד קוורום. לדוגמה, אפשר ליצור אשכול עבור בקר הדומיין של Active Directory כדי לספק שירותי דומיין עם זמינות גבוהה, וגם לספק את עדות שיתוף הקבצים בו-זמנית.
  • אפשר להשתמש בתוכנה לשכפול נתונים, כמו SIOS Datakeeper, עם Windows Failover Server Clustering לשכפול סינכרוני או אסינכרוני.

כדי ליצור את שיתוף הקבצים עבור העד:

  1. מתחברים אל wsfc-dc. השרת הזה מארח את שיתוף הקבצים.
  2. ב-Explorer, עוברים אל כונן C.
  3. בסרגל הכותרת, לוחצים על הלחצן תיקייה חדשה.
  4. נותנים לתיקייה החדשה את השם shares.
  5. לוחצים לחיצה כפולה על התיקייה shares כדי לפתוח אותה.
  6. מוסיפים תיקייה חדשה ונותנים לה את השם clusterwitness-testcluster.

הגדרת שיתוף עבור העד לשיתוף קבצים

צריך להגדיר הרשאות בתיקיית העדות של שיתוף הקבצים כדי לאפשר לאשכול להשתמש בה.

  1. בסייר, לוחצים לחיצה ימנית על התיקייה clusterwitness-testcluster ובוחרים באפשרות מאפיינים.
  2. בכרטיסייה שיתוף, לוחצים על שיתוף מתקדם.
  3. בוחרים באפשרות שיתוף התיקייה הזו.
  4. לוחצים על Permissions ואז על Add.
  5. לוחצים על סוגי אובייקטים, בוחרים באפשרות מחשבים ולוחצים על אישור.
  6. מוסיפים את חשבון המכונה testcluster$.
  7. נותנים הרשאות שליטה מלאה ל-testcluster$.
  8. לוחצים על אישור וסוגרים את כל תיבות הדו-שיח.

הוספת העד לקובץ המשותף לאשכול הגיבוי

עכשיו מגדירים את אשכול הגיבוי למקרה כשל כך שישתמש בעדות לשיתוף קבצים כהצבעה להשגת קוורום.

  1. במחשב שמארח את משאבי האשכול (wsfc-1), פותחים את Failover Cluster Manager.
  2. בחלונית הימנית, לוחצים לחיצה ימנית על שם האשכול (testcluster.WSFC.TEST), מצביעים על פעולות נוספות ואז לוחצים על הגדרת קוורום באשכול.
  3. בחלונית Select Quorum Configuration Option (בחירת אפשרות להגדרת קוורום), בוחרים באפשרות Select the quorum witness (בחירת עֵד לקוורום).
  4. בחלונית Select Quorum Witness, בוחרים באפשרות Configure a file share witness.
  5. בשדה File Share Path (נתיב לשיתוף קבצים), מזינים את הנתיב לתיקייה המשותפת, כמו \\wsfc-dc\clusterwitness-testcluster.
  6. מאשרים את ההגדרות ולוחצים על סיום.

בדיקה של אשכול הגיבוי

אשכול הגיבוי האוטומטי של Windows Server אמור לפעול עכשיו. אתם יכולים לבדוק את ההעברה הידנית של משאבי אשכול בין המופעים. עדיין לא סיימתם, אבל זה זמן טוב לוודא שכל מה שעשיתם עד עכשיו עובד.

  1. ב-wsfc-1, רושמים את השם של Current Host Server ב-Failover Cluster Manager.
  2. מריצים את Windows PowerShell בתור cluster-admin.

  3. ב-PowerShell, מריצים את הפקודה הבאה כדי לשנות את שרת המארח הנוכחי:

    Move-ClusterGroup -Name "Cluster Group"

השם של שרת המארח הנוכחי ישתנה לשם של המכונה הווירטואלית השנייה.

אם הבעיה לא נפתרה, כדאי לעיין בשלבים הקודמים ולבדוק אם פספסתם משהו. הבעיה הכי נפוצה היא כלל חומת אש חסר שחוסם את הגישה לרשת. בקטע פתרון בעיות מפורטות בעיות נוספות שכדאי לבדוק.

אחרת, אפשר להמשיך להגדרת מאזן העומסים הפנימי, שנדרש כדי לנתב את תעבורת הרשת לשרת המארח הנוכחי באשכול.

זה זמן טוב לצלם תמונות.

הוספת תפקיד לאשכול מעבר לגיבוי בעת כשל

ב-Windows failover clustering, ‏ תפקידים מארחים עומסי עבודה באשכול. אפשר להשתמש בתפקיד כדי לציין באשכול את כתובת ה-IP שבה האפליקציה משתמשת. במדריך הזה, מוסיפים תפקיד לעומס העבודה של הבדיקה, שהוא שרת האינטרנט של Internet Information Services ‏ (IIS), ומקצים כתובת IP לתפקיד.

שמירת כתובת IP לתפקיד ב-Compute Engine

כדי למנוע התנגשויות של כתובות IP ברשת המשנה ב-Compute Engine, צריך לשריין את כתובת ה-IP לתפקיד.

  1. פותחים טרמינל במכונת VM מארחת או פותחים את Cloud Shell.

    כניסה ל-Cloud Shell

  2. שמירת כתובת IP. במדריך הזה נשתמש ב-10.0.0.9:

    gcloud compute addresses create load-balancer-ip --region [YOUR_REGION] --subnet wsfcnetsub1 --addresses 10.0.0.9

  3. כדי לאשר את שמירת כתובת ה-IP:

    gcloud compute addresses list

הוספת התפקיד

איך לעשות את זה?

  1. ב-Failover Cluster Manager, בחלונית Actions, בוחרים באפשרות Configure Role.
  2. בדף Select Role (בחירת תפקיד), בוחרים באפשרות Other Server (שרת אחר).
  3. בדף Client Access Point (נקודת גישה ללקוח), מזינים את השם IIS.
  4. מגדירים את הכתובת ל-10.0.0.9.
  5. מדלגים על Select Storage ועל Select Resource Types.
  6. מאשרים את ההגדרות ולוחצים על סיום.

תיבת דו-שיח לאישור שבה מוצגות ההגדרות של התפקיד.

יצירת מאזן עומסים פנימי

יוצרים ומגדירים את מאזן העומסים הפנימי, שנדרש כדי לנתב את תעבורת הרשת לצומת המארח הפעיל של האשכול. תשתמשו במסוףGoogle Cloud , כי ממשק המשתמש מאפשר לכם לראות איך מאורגן איזון העומסים הפנימי.

בנוסף, תיצרו קבוצת מופעי מכונה ב-Compute Engine לכל אזור באשכול, שמאזן העומסים ישתמש בה כדי לנהל את הצמתים באשכול.

יצירת קבוצות של מופעים

יוצרים קבוצת מופעים בכל אזור שמכילה צומת של אשכול, ואז מוסיפים כל צומת לקבוצת המופעים באזור שלו. אל תוסיפו את בקר הדומיין wsfc-dc לקבוצת מופעים.

  1. יוצרים קבוצת מכונות לכל תחום באשכול, ומחליפים את הערך [ZONE_1] בשם של התחום הראשון ואת הערך [ZONE_2] בשם של התחום השני:

    gcloud compute instance-groups unmanaged create wsfc-group-1 --zone=[ZONE_1]
     
    gcloud compute instance-groups unmanaged create wsfc-group-2 --zone=[ZONE_2]

  2. מוסיפים את השרת בכל אזור לקבוצת המופעים של אותו אזור:

    gcloud compute instance-groups unmanaged add-instances wsfc-group-1 --instances wsfc-1 --zone [ZONE_1]
     
    gcloud compute instance-groups unmanaged add-instances wsfc-group-2 --instances wsfc-2 --zone [ZONE_2]

  3. בודקים שקבוצות המופעים נוצרו וכל קבוצה מכילה מופע אחד:

    gcloud compute instance-groups unmanaged list
     
      NAME          ZONE           NETWORK  NETWORK_PROJECT   MANAGED  INSTANCES
  wsfc-group-1  us-central1-a  wsfcnet  exampleproject    No       1
  wsfc-group-2  us-central1-b  wsfcnet  exampleproject    No       1

יצירת מאזן העומסים

התחלת ההגדרה

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על Create load balancer (יצירת מאזן עומסים).
  3. בקטע Type of load balancer (סוג מאזן העומסים), בוחרים באפשרות Network Load Balancer (TCP/UDP/SSL) (מאזן עומסים ברשת (TCP/UDP/SSL)) ולוחצים על Next (הבא).
  4. בקטע Proxy or passthrough (פרוקסי או העברה), בוחרים באפשרות Passthrough load balancer (מאזן עומסים להעברה) ולוחצים על Next (הבא).
  5. בקטע Public facing or internal (פנימי או גלוי לכולם), בוחרים באפשרות Internal (פנימי) ולוחצים על Next (הבא).
  6. לוחצים על Configure (הגדרה).

הגדרה בסיסית

  1. בשדה Name (שם), מזינים wsfc-lb.
  2. בוחרים את האזור הנוכחי.
  3. לוחצים על wsfcnet ליד רשת.

הגדרת הקצה העורפי

כדאי לזכור שמאזן העומסים הפנימי של Google Cloud משתמש בבדיקת תקינות תקופתית כדי לקבוע את הצומת הפעיל. במהלך בדיקת תקינות, מתבצע פינג לסוכן המארח של אשכול Compute Engine שפועל בצומת הפעיל של האשכול. המטען הייעודי (payload) של בדיקת התקינות הוא כתובת ה-IP של האפליקציה, שמיוצגת על ידי התפקיד המקובץ. הסוכן משיב עם הערך 1 אם הצומת פעיל או עם הערך 0 אם הוא לא פעיל.

  1. לוחצים על Backend configuration.
  2. בקטע Backends, מוסיפים כל קבוצת מופעים שיצרתם על ידי בחירת השם שלה ולחיצה על Done.

  3. יצירת בדיקת תקינות.

    • בשדה Name (שם), מזינים wsfc-hc.
    • מאשרים את הגדרת ברירת המחדל של פרוטוקול, שהיא TCP, ומשנים את היציאה ל-59998 לתשובות של סוכן המארח של האשכול.
    • בשדה בקשה, מזינים '10.0.0.9'.
    • בשדה תגובה, מזינים '1'.
    • בשדה Check interval (מרווח הבדיקה), מזינים את הערך 2.
    • בשדה Timeout (זמן קצוב לתפוגה), מזינים '1'.
    • לוחצים על שמירה והמשך.

הגדרת הקצה הקדמי

ההגדרה של הקצה הקדמי יוצרת כלל העברה שמגדיר איך מאזן העומסים מטפל בבקשות נכנסות. כדי לפשט את המדריך הזה, תבדקו את המערכת על ידי שליחת בקשות בין המכונות הווירטואליות ברשת המשנה.

במערכת הייצור, סביר להניח שתרצו לפתוח את המערכת לתנועה חיצונית, כמו תנועה באינטרנט. כדי לעשות את זה, אפשר ליצור יעד מבוצר (bastion host) שמקבל תעבורת נתונים חיצונית ומעביר אותה לרשת הפנימית. ההדרכה הזו לא כוללת הסבר על שימוש ביעד מבוצר (bastion host).

  1. בחלונית המרכזית, לוחצים על Frontend configuration.
  2. בשדה Name (שם), מזינים wsfc-lb-fe.
  3. בוחרים את רשת המשנה (wsfcnetsub1).
  4. בשדה כתובת IP פנימית, בוחרים באפשרות load-balancer-ip (10.0.0.9). זו אותה כתובת IP שהגדרתם לתפקיד.
  5. בשדה יציאות, מזינים '80'.
  6. לוחצים על סיום.

בדיקה וסיום

  1. כדי לראות סיכום של הגדרות איזון העומסים הפנימי, בחלונית המרכזית לוחצים על בדיקה וסיום. הסיכום יופיע בחלונית השמאלית.

  2. לוחצים על יצירה. יצירת מאזן העומסים לוקחת כמה רגעים.

    ‫Google Cloud במסוף מוצגות ההגדרות הסופיות של איזון עומסים פנימי.

יצירת כללים לחומת האש עבור בדיקת התקינות

יכול להיות ששמתם לב שהמערכת של Google Cloud מסוף Google Cloud הודיעה לכם שצריך להגדיר כלל בחומת האש כדי שבדיקות התקינות יוכלו להגיע ליעדים שלהן. בקטע הזה מגדירים את הכלל בחומת האש.

  1. במסוף Google Cloud , עוברים אל Cloud Shell.

    כניסה ל-Cloud Shell

  2. מריצים את הפקודה הבאה כדי ליצור את הכלל בחומת האש:

    gcloud compute firewall-rules create allow-health-check --network wsfcnet --source-ranges 130.211.0.0/22,35.191.0.0/16 --allow tcp:59998

פתיחת חומת האש של Windows

בכל צומת של האשכול, wsfc-1 ו-wsfc-2, יוצרים כלל חומת אש בחומת האש של Windows כדי לאפשר למאזן העומסים לגשת לכל מערכת Windows.

  1. פותחים את האפליקציה 'חומת האש של Windows עם אבטחה מתקדמת'.

  2. בחלונית הניווט שמימין, בוחרים באפשרות כללים לתעבורה נכנסת.

  3. בחלונית הניווט השמאלית, לוחצים על כלל חדש.

  4. בחלונית סוג הכלל, בוחרים באפשרות בהתאמה אישית כסוג הכלל ולוחצים על הבא.

  5. בחלונית Program, מאשרים את ברירת המחדל ולוחצים על Next.

  6. בחלונית Protocol and Ports:

    1. בשדה סוג הפרוטוקול:, בוחרים באפשרות TCP.
    2. בשדה Local port: (יציאה מקומית), בוחרים באפשרות Specific Ports (יציאות ספציפיות) ומזינים את 59998.

  7. בחלונית Scope, בקטע Which remote IP addresses does this rule apply to:

    1. בוחרים באפשרות כתובות ה-IP האלה:.

    2. מוסיפים כל אחת מכתובות ה-IP הבאות לשדה This IP address or subnet (כתובת ה-IP או רשת המשנה הזו) על ידי לחיצה על Add (הוספה):

      • 130.211.0.0/22
      • 35.191.0.0/16

    3. לוחצים על הבא.

  8. בחלונית פעולה, מאשרים את האפשרות התרת החיבור ולוחצים על הבא.

  9. בחלונית Profile, מאשרים את אפשרויות ברירת המחדל ולוחצים על Next.

  10. מציינים שם לכלל חומת האש ולוחצים על סיום.

אימות מאזן העומסים

אחרי שהמאזן הפנימי של עומסי העבודה פועל, אפשר לבדוק את הסטטוס שלו כדי לוודא שהוא יכול למצוא מכונה תקינה, ואז לבדוק שוב את יתירות הכשל.

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. לוחצים על השם של מאזן העומסים (wsfc-lb).

    בקטע Backend של הסיכום, אמורות להופיע קבוצות המופעים.

    בתמונה הבאה מדף הפרטים של מאזן העומסים wsfc-lb, קבוצת המופעים wsfc-group-1 מכילה את הצומת הפעיל, כפי שמצוין על ידי 1 / 1 בעמודה Healthy. קבוצת המופעים wsfc-group-2 מכילה את הצומת הלא פעיל, כפי שמצוין ב-0 / 1.

    הסטטוס של איזון העומסים מראה 1 מתוך 1 מופעים תקינים בקבוצת המופעים wsfc-group-1, מה שמציין שהיא מכילה את הצומת הפעיל.

    אם בשתי קבוצות המופעים מופיע הערך 0 / 1, יכול להיות שמאזן העומסים עדיין מסתנכרן עם הצמתים. לפעמים צריך לבצע לפחות פעולת מעבר לגיבוי כדי שמאזן העומסים ימצא את כתובת ה-IP.

  3. ב-Failover Cluster Manager, מרחיבים את שם האשכול ולוחצים על Roles (תפקידים). בעמודה Owner Node (צומת הבעלים), רושמים את שם השרת של התפקיד IIS.

  4. כדי להתחיל בהעברה אוטומטית לגיבוי, לוחצים לחיצה ימנית על התפקיד IIS ובוחרים באפשרות העברה > הצומת הטוב ביותר האפשרי. הפעולה הזו מעבירה את התפקיד לצומת השני, כמו שמוצג בעמודה צומת הבעלים.

    השדה Owner Node מוצג במנהל של אשכולות מעבר לגיבוי.

  5. מחכים עד שהסטטוס פועל יופיע בעמודה סטטוס.

  6. חוזרים לדף Load balancer details (פרטי איזון העומסים), לוחצים על Refresh (רענון) ומוודאים שהערכים 1 / 1 ו-0 / 1 בעמודה Healthy (תקין) החליפו קבוצות של מופעים.

    בסטטוס של מאזן העומסים מוצג מופע תקין אחד מתוך 2. 

gcloud compute backend-services get-health wsfc-lb --region=[REGION]

הפלט אמור להיראות כך:

backend: https://compute.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-a/instanceGroups/wsfc-group-1
status:
  healthStatus:
  - healthState: HEALTHY
    instance: https://compute.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-a/instances/wsfc-1
    ipAddress: 10.0.0.4
    port: 80
  kind: compute#backendServiceGroupHealth
---
backend: https://compute.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-b/instanceGroups/wsfc-group-2
status:
  healthStatus:
  - healthState: UNHEALTHY
    instance: https://compute.googleapis.com/compute/v1/projects/exampleproject/zones/us-central1-b/instances/wsfc-2
    ipAddress: 10.0.0.5
    port: 80
  kind: compute#backendServiceGroupHealth

התקנת האפליקציה

אחרי שיש לכם אשכול, אתם יכולים להגדיר את האפליקציה בכל צומת ולהגדיר אותה להפעלה בסביבה של אשכול.

כדי לבצע את המדריך הזה, צריך להגדיר משהו שיכול להדגים שהאשכול באמת עובד עם מאזן העומסים הפנימי. מגדירים את IIS בכל מכונה וירטואלית כדי להציג דף אינטרנט פשוט.

אתם לא מגדירים IIS לזמינות גבוהה באשכול. אתם יוצרים מופעים נפרדים של IIS, שכל אחד מהם מציג דף אינטרנט שונה. אחרי מעבר לגיבוי, שרת האינטרנט מציג את התוכן שלו ולא תוכן משותף.

הגדרת האפליקציה או IIS לזמינות גבוהה היא מעבר להיקף של המדריך הזה.

הגדרה של IIS

  1. בכל צומת באשכול, מתקינים את IIS.

    • בדף Select role services (בחירת שירותי תפקידים), מוודאים שהאפשרות Default Document (מסמך ברירת מחדל) מסומנת בקטע Common HTTP Features (תכונות HTTP נפוצות).
    • בדף אישור, מסמנים את תיבת הסימון להפעלה מחדש אוטומטית של שרת היעד.

  2. מוודאים שכל שרת אינטרנט פועל.

    1. משתמשים ב-RDP כדי להתחבר למכונה הווירטואלית שנקראת wsfc-dc.
    2. ב-Server Manager, לוחצים על Local Server בחלונית הניווט בצד ימין של החלון.
    3. בקטע Properties (מאפיינים) בחלק העליון, משביתים את האפשרות IE Enhanced Security Configuration (הגדרת אבטחה משופרת של IE).
    4. פותחים את Internet Explorer.

    5. עוברים לכתובת ה-IP של כל שרת:

      http://10.0.0.4/
       
      http://10.0.0.5/

בכל מקרה, מוצג הדף Welcome, שהוא דף האינטרנט שמוגדר כברירת מחדל ב-IIS.

עריכת דפי האינטרנט שמוגדרים כברירת מחדל

משנים כל דף אינטרנט שמוגדר כברירת מחדל כדי שיהיה קל לראות איזה שרת מציג את הדף כרגע.

  1. משתמשים ב-RDP כדי להתחבר למכונה הווירטואלית שנקראת wsfc-1.
  2. מפעילים את פנקס הרשימות כאדמין.
  3. פותחים את הקובץ C:\inetpub\wwwroot\iisstart.htm בפנקס הרשימות. חשוב לעיין בכל הקבצים, ולא רק בקובצי טקסט.

  4. ברכיב <title>, משנים את הטקסט לשם של השרת הנוכחי. לדוגמה:

        <title>wsfc-1</title>

  5. שומרים את קובץ ה-HTML.

  6. חוזרים על השלבים האלה עבור wsfc-2 ומגדירים את הרכיב <title> בתור wsfc-2.

מעכשיו, כשצופים בדף אינטרנט שמוצג מאחד השרתים האלה, שם השרת מופיע ככותרת בכרטיסייה של Internet Explorer.

בדיקת המעבר לגיבוי

  1. משתמשים ב-RDP כדי להתחבר למכונה הווירטואלית שנקראת wsfc-dc.
  2. פותחים את Internet Explorer.

  3. עוברים לכתובת ה-IP של תפקיד מאזן העומסים:

    http://10.0.0.9/

    מוצג הדף Welcome עם שם השרת הנוכחי בכותרת הכרטיסייה.

  4. מפסיקים את השרת הנוכחי כדי לדמות כשל. ב-Cloud Shell, מריצים את הפקודה הבאה ומחליפים את [INSTANCE_NAME] בשם השרת הנוכחי שמופיע בשלב הקודם, למשל wsfc-1:

    gcloud compute instances stop [INSTANCE_NAME] --zone=[ACTIVE_ZONE]

  5. עוברים לחיבור RDP אל wsfc-dc.

    יכול להיות שיעברו כמה רגעים עד שמאזן העומסים יזהה את ההעברה וינתב מחדש את התנועה.

  6. אחרי כ-30 שניות, מרעננים את הדף ב-Internet Explorer.

    עכשיו שם הצומת הפעיל החדש אמור להופיע בכותרת הכרטיסייה. לדוגמה, אם התחלתם עם wsfc-1 פעיל, עכשיו יופיע wsfc-2 בכותרת. אם השינוי לא מופיע מיד או שמוצגת שגיאה 'הדף לא נמצא', צריך לרענן שוב את הדפדפן.

כל הכבוד! עכשיו יש לכם אשכול מעבר לגיבוי בעל תפקוד מלא של Windows Server 2016 שפועל ב- Google Cloud.

פתרון בעיות

ריכזנו כאן כמה בעיות נפוצות שכדאי לבדוק אם משהו לא עובד.

Google Cloud כללי חומת האש חוסמים את בדיקת התקינות

אם בדיקת התקינות לא פועלת, צריך לוודא שיש לכם כלל חומת אש שמאפשר תעבורת נתונים נכנסת מכתובות ה-IP שבהן משתמשת מערכת בדיקת התקינות: 130.211.0.0/22 ו-35.191.0.0/16.

חומת האש של Windows חוסמת את בדיקת התקינות

מוודאים שהיציאה 59998 פתוחה בחומת האש של Windows בכל צומת באשכול. איך פותחים את חומת האש של Windows

צמתי אשכול באמצעות DHCP

חשוב שלכל מכונה וירטואלית באשכול תהיה כתובת IP סטטית. אם מכונה וירטואלית מוגדרת לשימוש ב-DHCP ב-Windows, צריך לשנות את הגדרות הרשת ב-Windows כדי שכתובת ה-IPv4 תהיה זהה לכתובת ה-IP של המכונה הווירטואלית, כפי שמוצג במסוף Google Cloud . צריך גם להגדיר את כתובת ה-IP של השער כך שתהיה זהה לכתובת של שער רשת המשנה ב- Google Cloud VPC.

Google Cloud תגי רשת בכללים של חומת האש

אם אתם משתמשים בתגי רשת בכללי חומת האש, הקפידו להגדיר את התגים הנכונים בכל מכונה וירטואלית. במדריך הזה לא נעשה שימוש בתגים, אבל אם הגדרתם אותם מסיבה אחרת, אתם צריכים להשתמש בהם באופן עקבי.

הסרת המשאבים

כדי להימנע מחיובים בחשבון Google Cloud בגלל השימוש במשאבים שנעשה במסגרת המדריך הזה, אפשר למחוק את הפרויקט שמכיל את המשאבים או להשאיר את הפרויקט ולמחוק את המשאבים בנפרד.

אחרי שמסיימים את המדריך, אפשר למחוק את המשאבים שנוצרו, כדי שהם יפסיקו להשתמש במכסה ולצבור חיובים. בסעיפים הבאים מוסבר איך למחוק או להשבית את המשאבים האלו.

מחיקת הפרויקט

הדרך הקלה ביותר לבטל את החיוב היא למחוק את הפרויקט שיצרתם בשביל המדריך.

כדי למחוק את הפרויקט:

  1. במסוף Google Cloud , נכנסים לדף Manage resources.

    כניסה לדף Manage resources

  2. ברשימת הפרויקטים, בוחרים את הפרויקט שרוצים למחוק ולוחצים על Delete.
  3. כדי למחוק את הפרויקט, כותבים את מזהה הפרויקט בתיבת הדו-שיח ולוחצים על Shut down.

פינוי משאבים בלי למחוק את הפרויקט

אם אתם צריכים לשמור את הפרויקט, תוכלו למחוק את המשאבים של המדריך בנפרד כדי לנקות אותם.

מחיקת מכונות

כדי למחוק מכונה של Compute Engine:

  1. נכנסים לדף VM instances במסוף Google Cloud .

    כניסה לדף VM instances

  2. מסמנים את התיבה שלצד המופע שרוצים למחוק.
  3. כדי למחוק את המכונה, לוחצים על More actions ואז על Delete ופועלים לפי ההוראות.

מחיקת קבוצות של מכונות

  1. נכנסים לדף Instance groups במסוף Google Cloud .

    כניסה לדף Instance groups

  2. מסמנים את התיבה שלצד קבוצת המכונות שרוצים למחוק.
  3. כדי למחוק את קבוצות המכונות, לוחצים על Delete.

מחיקת מאזן עומסים

כדי למחוק מאזן עומסים:

  1. נכנסים לדף Load balancing במסוף Google Cloud .

    כניסה לדף Load balancing

  2. מסמנים את התיבה שליד השם של מאזן העומסים שרוצים למחוק.

  3. לוחצים על הלחצן מחיקה בחלק העליון של הדף.

מחיקת רשת VPC

כדי למחוק רשת VPC:

  1. נכנסים לדף VPC networks במסוף Google Cloud .

    מעבר לרשתות VPC

  2. לוחצים על שם הרשת שרוצים למחוק.

  3. לוחצים על הלחצן מחיקת רשת VPC בחלק העליון של הדף.

שחרור כתובות IP שמורות

משתמשים ב-Cloud Shell כדי לשחרר את כתובות ה-IP השמורות:

  1. במסוף Google Cloud , עוברים אל Cloud Shell.

    כניסה ל-Cloud Shell

  2. משחררים את כתובות ה-IP השמורות:

    gcloud compute addresses delete cluster-access-point load-balancer-ip

מחיקת דיסקים לאחסון מתמיד

כדי למחוק דיסק מתמשך:

  1. נכנסים לדף Disks במסוף Google Cloud .

    לפתיחת הדף Disks

  2. מסמנים את התיבה שליד השם של הדיסק שרוצים למחוק.

  3. לוחצים על הלחצן מחיקה בחלק העליון של הדף.

המאמרים הבאים