במאמר הזה מפורטות הוראות להגדרת מאזן עומסים פנימי בשרתי Proxy אזוריים עבור השירותים שפועלים במכונות וירטואליות ב-Compute Engine.
לפני שמתחילים
לפני שתמשיכו לקרוא את המדריך הזה, כדאי שתכירו את המושגים הבאים:
הרשאות
כדי לפעול לפי המדריך הזה, אתם צריכים להיות מסוגלים ליצור מופעים ולשנות רשת בפרויקט. צריכות להיות לכם הרשאות בעלים או עריכה בפרויקט, או כל תפקידי ה-IAM הבאים ב-Compute Engine.
| משימה | התפקיד הנדרש |
|---|---|
| יצירת רשתות, רשתות משנה ורכיבים של מאזן עומסים | אדמין של רשת מחשוב |
| הוספה והסרה של כללים לחומת האש | אדמין לענייני אבטחה ב-Compute |
| יצירת מופעים | אדמין מכונות של Compute |
מידע נוסף זמין במדריכים הבאים:
סקירה כללית של ההגדרה
אפשר להגדיר את מאזן העומסים כמו שמוצג בתרשים הבא:
כפי שמוצג בדיאגרמה, בדוגמה הזו נוצר מאזן עומסי רשת פנימי חוצה אזורים ברשת VPC, עם שירות לקצה העורפי אחד ושתי קבוצות מופעי מכונה מנוהלים (MIG) בקצה העורפי באזורים REGION_A ו-REGION_B.
הדיאגרמה מציגה את הפריטים הבאים:
רשת VPC עם רשתות המשנה הבאות:
- תת-רשת
SUBNET_Aותת-רשת של שרת proxy בלבד ב-REGION_A. - תת-רשת
SUBNET_Bותת-רשת של שרת proxy בלבד ב-REGION_B.
צריך ליצור רשתות משנה מסוג proxy-only בכל אזור של רשת VPC שבה משתמשים במאזני עומסים פנימיים ברשת מסוג proxy חוצה אזורים. תת-הרשת של ה-proxy בלבד באזור משותפת לכל מאזני העומסים הפנימיים של הרשת בשרת proxy באזור. כתובות המקור של מנות שנשלחות ממאזן העומסים לקצה העורפי של השירות מוקצות מרשת המשנה של ה-proxy בלבד. בדוגמה הזו, לתת-הרשת של שרת proxy בלבד באזור
REGION_Bיש טווח כתובות IP ראשי של10.129.0.0/23, ולתת-הרשת באזורREGION_Aיש טווח כתובות IP ראשי של10.130.0.0/23, שהוא הגודל המומלץ של תת-הרשת.- תת-רשת
ההגדרה של זמינות גבוהה כוללת קצוות עורפיים של קבוצות מופעים מנוהלות לפריסות של מכונות וירטואליות ב-Compute Engine באזורים
REGION_Aו-REGION_B. אם הבק-אנד באזור אחד מושבת, התעבורה עוברת לאזור השני.שירות גלובלי לקצה העורפי שעוקב אחרי השימוש בקצה העורפי והתקינות שלו.
שרת proxy של TCP ביעד גלובלי, שמקבל בקשה מהמשתמש ומעביר אותה לשירות הקצה העורפי.
כללי העברה גלובליים, שכוללים את כתובת ה-IP הפנימית האזורית של מאזן העומסים ויכולים להעביר כל בקשה נכנסת אל שרת ה-proxy של היעד.
כתובת ה-IP הפנימית שמשויכת לכלל ההעברה יכולה להגיע מתת-רשת באותה רשת ואותו אזור כמו שרתי הבק-אנד. חשוב לזכור את התנאים הבאים:
- כתובת ה-IP יכולה להיות (אבל לא חייבת) מאותה רשת משנה כמו קבוצות השרתים העורפיים.
- כתובת ה-IP לא יכולה להיות מתת-רשת שמורה של שרת proxy בלבד, שמוגדר בה הדגל
--purposeלערךGLOBAL_MANAGED_PROXY. - אם רוצים להשתמש באותה כתובת IP פנימית עם כמה כללי העברה, צריך להגדיר את הדגל של כתובת ה-IP
--purposeלערךSHARED_LOADBALANCER_VIP.
הגדרת הרשתות ורשתות המשנה
ברשת ה-VPC, מגדירים רשת משנה בכל אזור שבו הוגדרו השרתים העורפיים. בנוסף, צריך להגדיר proxy-only-subnetבכל אזור שבו רוצים להגדיר את מאזן העומסים.
בדוגמה הזו נעשה שימוש ברשת VPC, באזור ובתת-רשתות הבאים:
רשת. הרשת היא רשת VPC במצב מותאם אישית בשם
NETWORK.תת-רשתות לשרתי קצה עורפיים.
- רשת משנה בשם
SUBNET_AבאזורREGION_Aמשתמשת ב-10.1.2.0/24כטווח ה-IP הראשי שלה. - רשת משנה בשם
SUBNET_BבאזורREGION_Bמשתמשת ב-10.1.3.0/24כטווח ה-IP הראשי שלה.
- רשת משנה בשם
תת-רשתות לשרתי Proxy.
- רשת משנה בשם
PROXY_SN_AבאזורREGION_Aמשתמשת ב-10.129.0.0/23כטווח ה-IP הראשי שלה. - רשת משנה בשם
PROXY_SN_BבאזורREGION_Bמשתמשת ב-10.130.0.0/23כטווח כתובות ה-IP הראשי שלה.
- רשת משנה בשם
אפשר לגשת למאזני עומסים פנימיים של אפליקציות (ALB) בין אזורים מכל אזור ב-VPC. כך לקוחות מכל אזור יכולים לגשת לשרתי הבק-אנד של מאזן העומסים שלכם באופן גלובלי.
הגדרת רשתות המשנה של הקצה העורפי
המסוף
נכנסים לדף VPC networks במסוף Google Cloud .
לוחצים על יצירת רשת VPC.
מזינים שם לרשת.
בקטע רשתות משנה, מגדירים את מצב יצירת רשתות משנה למותאם אישית.
יוצרים רשת משנה לשרתי הבק-אנד של מאזן העומסים. בקטע New subnet (רשת משנה חדשה), מזינים את הפרטים הבאים:
- מזינים שם לרשת המשנה.
- בוחרים אזור: REGION_A
- מזינים טווח כתובות IP:
10.1.2.0/24
לוחצים על סיום.
לוחצים על הוספת רשת משנה.
יוצרים רשת משנה לשרתי הבק-אנד של מאזן העומסים. בקטע New subnet, מזינים את הפרטים הבאים:
- מזינים שם לרשת המשנה.
- בוחרים אזור: REGION_B
- מזינים טווח כתובות IP:
10.1.3.0/24
לוחצים על סיום.
לוחצים על יצירה.
gcloud
יוצרים את רשת ה-VPC המותאמת אישית באמצעות הפקודה
gcloud compute networks create:gcloud compute networks create NETWORK \ --subnet-mode=customיוצרים תת-רשת ברשת
NETWORKבאזורREGION_Aבאמצעות הפקודהgcloud compute networks subnets create:gcloud compute networks subnets create SUBNET_A \ --network=NETWORK \ --range=10.1.2.0/24 \ --region=REGION_Aיוצרים תת-רשת ברשת
NETWORKבאזורREGION_Bבאמצעות הפקודהgcloud compute networks subnets create:gcloud compute networks subnets create SUBNET_B \ --network=NETWORK \ --range=10.1.3.0/24 \ --region=REGION_B
Terraform
כדי ליצור את רשת ה-VPC, משתמשים במשאב google_compute_network.
כדי ליצור את תת-הרשתות של ה-VPC ברשת lb-network-crs-reg, משתמשים במשאב google_compute_subnetwork.
API
שולחים בקשת POST אל ה-method networks.insert.
מחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks
{
"routingConfig": {
"routingMode": "regional"
},
"name": "NETWORK",
"autoCreateSubnetworks": false
}
שולחים בקשת POST אל ה-method subnetworks.insert.
מחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks
{
"name": "SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/lb-network-crs-reg",
"ipCidrRange": "10.1.2.0/24",
"region": "projects/PROJECT_ID/regions/REGION_A",
}
שולחים בקשת POST אל ה-method subnetworks.insert.
מחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks
{
"name": "SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"ipCidrRange": "10.1.3.0/24",
"region": "projects/PROJECT_ID/regions/REGION_B",
}
הגדרת רשת המשנה ל-proxy בלבד
תת-רשת של פרוקסי בלבד מספקת קבוצה של כתובות IP ש- Google Cloud משתמש בהן כדי להריץ פרוקסי Envoy בשמכם. הפרוקסיים מסיימים חיבורים מהלקוח ויוצרים חיבורים חדשים לשרתי הקצה.
כל מאזני העומסים האזוריים שמבוססים על Envoy באותו אזור כמו רשת ה-VPC משתמשים בתת-הרשת הזו שמשמשת רק כ-proxy. יכולה להיות רק תת-רשת אחת פעילה מסוג proxy-only לכל מטרה נתונה, לכל אזור ולכל רשת.
המסוף
אם אתם משתמשים במסוף Google Cloud , אתם יכולים לחכות וליצור את רשת המשנה של ה-proxy בלבד בהמשך בדף איזון עומסים.
כדי ליצור עכשיו את רשת המשנה של ה-proxy בלבד, פועלים לפי השלבים הבאים:
נכנסים לדף VPC networks במסוף Google Cloud .
- לוחצים על השם של רשת ה-VPC.
- בכרטיסייה Subnet, לוחצים על Add subnet.
- מזינים שם לרשת המשנה של ה-proxy בלבד.
- בוחרים אזור: REGION_A
- ברשימה Purpose בוחרים באפשרות Cross-region Managed Proxy.
- בשדה טווח כתובות IP, מזינים
10.129.0.0/23. - לוחצים על הוספה.
יצירת תת-רשת לשרת proxy בלבד ב-REGION_B
- בכרטיסייה Subnet, לוחצים על Add subnet.
- מזינים שם לרשת המשנה של ה-proxy בלבד.
- בוחרים אזור: REGION_B
- ברשימה Purpose בוחרים באפשרות Cross-region Managed Proxy.
- בשדה טווח כתובות IP, מזינים
10.130.0.0/23. - לוחצים על הוספה.
gcloud
יוצרים את רשתות המשנה של ה-proxy בלבד באמצעות הפקודה
gcloud compute networks subnets create.
gcloud compute networks subnets create PROXY_SN_A \
--purpose=GLOBAL_MANAGED_PROXY \
--role=ACTIVE \
--region=REGION_A \
--network=NETWORK \
--range=10.129.0.0/23
gcloud compute networks subnets create PROXY_SN_B \
--purpose=GLOBAL_MANAGED_PROXY \
--role=ACTIVE \
--region=REGION_B \
--network=NETWORK \
--range=10.130.0.0/23
Terraform
כדי ליצור את רשת המשנה של ה-VPC מסוג proxy בלבד ברשת lb-network-crs-reg, משתמשים במשאב google_compute_subnetwork.
API
יוצרים את רשתות המשנה של ה-proxy בלבד באמצעות
השיטה subnetworks.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_A/subnetworks
{
"name": " PROXY_SN_A",
"ipCidrRange": "10.129.0.0/23",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"region": "projects/PROJECT_ID/regions/REGION_A",
"purpose": "GLOBAL_MANAGED_PROXY",
"role": "ACTIVE"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/REGION_B/subnetworks
{
"name": "PROXY_SN_B",
"ipCidrRange": "10.130.0.0/23",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"region": "projects/PROJECT_ID/regions/REGION_B",
"purpose": "GLOBAL_MANAGED_PROXY",
"role": "ACTIVE"
}
הגדרת כללים לחומת אש
בדוגמה הזו נעשה שימוש בכללים הבאים של חומת האש:
fw-ilb-to-backends. כלל תעבורת נתונים נכנסת (ingress) שחל על המכונות שמתבצע עליהן איזון עומסים, שמאפשר קישוריות SSH נכנסת ביציאת TCP22מכל כתובת. אפשר לבחור טווח כתובות IP של מקור מוגבל יותר עבור הכלל הזה. לדוגמה, אפשר לציין רק את טווחי כתובות ה-IP של המערכת שממנה מתחילים סשנים של SSH. בדוגמה הזו, תג היעדallow-sshמשמש לזיהוי המכונות הווירטואליות שכלל חומת האש חל עליהן.
fw-healthcheck. כלל תעבורה נכנסת (ingress) שחל על המופעים שמתבצע בהם איזון עומסים, שמאפשר את כל תעבורת ה-TCP ממערכות בדיקת התקינות (ב- Google Cloud, ב-130.211.0.0/22וב-35.191.0.0/16). בדוגמה הזו נעשה שימוש בתג היעדload-balanced-backendכדי לזהות את המכונות הווירטואליות שהכלל של חומת האש חל עליהן.fw-backends. כלל תעבורת נתונים נכנסת (ingress) שחל על המכונות שעוברות איזון עומסים, שמאפשר תעבורת TCP ביציאות80,443ו-8080משרתי ה-proxy המנוהלים של מאזן העומסים הפנימי של הרשת לשרת proxy. בדוגמה הזו נעשה שימוש בתג היעדload-balanced-backendכדי לזהות את המכונות הווירטואליות שכלל חומת האש חל עליהן.
בלי כללי חומת האש האלה, הכלל default deny ingress חוסם תנועה נכנסת למופעי ה-Backend.
תגי היעד מגדירים את מופעי ה-Backend. בלי תגי היעד, כללי חומת האש חלים על כל מופעי ה-Backend ברשת ה-VPC. כשיוצרים את מכונות ה-VM של ה-Backend, חשוב לכלול את תגי היעד שצוינו, כמו שמוסבר במאמר יצירת קבוצת מופעים מנוהלת.
המסוף
נכנסים לדף Firewall policies במסוף Google Cloud .
לוחצים על יצירת כלל חומת אש כדי ליצור את הכלל שיאפשר חיבורי SSH נכנסים:
- Name (שם):
fw-ilb-to-backends - רשת: NETWORK
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: אישור
- יעדים: תגי יעד שצוינו
- תגי טירגוט:
allow-ssh - מסנן מקור: טווחים של IPv4
- טווחים של כתובות IPv4 של המקור:
0.0.0.0/0 - פרוטוקולים ויציאות:
- בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
- מסמנים את התיבה TCP ומזינים
22כמספר היציאה.
- Name (שם):
לוחצים על יצירה.
לוחצים על יצירת כלל לחומת האש בפעם השנייה כדי ליצור את הכלל שיאפשר בדיקות תקינות שלGoogle Cloud :
- Name (שם):
fw-healthcheck - רשת: NETWORK
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: אישור
- יעדים: תגי יעד שצוינו
- תגי טירגוט:
load-balanced-backend - מסנן מקור: טווחים של IPv4
- טווחי IPv4 של המקור:
130.211.0.0/22ו-35.191.0.0/16 פרוטוקולים ויציאות:
- בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
- מסמנים את התיבה TCP ומזינים
80כמספר היציאה.
מומלץ להגביל את הכלל הזה רק לפרוטוקולים ולפורטים שתואמים לאלה שמשמשים בבדיקת תקינות. אם משתמשים ב-
tcp:80לפרוטוקול וליציאה, Google Cloud יכול להשתמש ב-HTTP ביציאה80כדי ליצור קשר עם המכונות הווירטואליות, אבל הוא לא יכול להשתמש ב-HTTPS ביציאה443כדי ליצור איתן קשר.
- Name (שם):
לוחצים על יצירה.
לוחצים על Create firewall rule (יצירת כלל חומת אש) בפעם השלישית כדי ליצור את הכלל שיאפשר לשרתי ה-Proxy של מאזן העומסים להתחבר לשרתי הקצה:
- Name (שם):
fw-backends - רשת: NETWORK
- כיוון התנועה: כניסה
- פעולה במקרה של התאמה: אישור
- יעדים: תגי יעד שצוינו
- תגי טירגוט:
load-balanced-backend - מסנן מקור: טווחים של IPv4
- טווחי IPv4 של המקור:
10.129.0.0/23ו-10.130.0.0/23 - פרוטוקולים ויציאות:
- בוחרים באפשרות פרוטוקולים ויציאות שצוינו.
- מסמנים את התיבה TCP ומזינים את הערך
80, 443, 8080עבור מספרי היציאות.
- Name (שם):
לוחצים על יצירה.
gcloud
יוצרים את כלל חומת האש
fw-ilb-to-backendsכדי לאפשר קישוריות SSH למכונות וירטואליות עם תג הרשתallow-ssh. אם לא מציינים אתsource-ranges,Google Cloud מפרש את הכלל כאילו הוא מתייחס לכל מקור.gcloud compute firewall-rules create fw-ilb-to-backends \ --network=NETWORK \ --action=/proxy/https/docs.cloud.google.com/load-balancing/docs/tcp/allow \ --direction=ingress \ --target-tags=allow-ssh \ --rules=tcp:22יוצרים את הכלל
fw-healthcheckכדי לאפשר Google Cloudבדיקות תקינות. בדוגמה הזו, כל תנועת ה-TCP מבודקי בדיקת תקינות מורשית, אבל אפשר להגדיר קבוצה מצומצמת יותר של יציאות בהתאם לצרכים שלכם.gcloud compute firewall-rules create fw-healthcheck \ --network=NETWORK \ --action=/proxy/https/docs.cloud.google.com/load-balancing/docs/tcp/allow \ --direction=ingress \ --source-ranges=130.211.0.0/22,35.191.0.0/16 \ --target-tags=load-balanced-backend \ --rules=tcpיוצרים את הכלל
fw-backendsכדי לאפשר לשרתי ה-proxy של מאזן העומסים הפנימי לשרת proxy להתחבר לשרתים העורפיים. מגדירים אתsource-rangesלטווחים המוקצים של רשת המשנה של שרת proxy בלבד, לדוגמה,10.129.0.0/23ו-10.130.0.0/23.gcloud compute firewall-rules create fw-backends \ --network=NETWORK \ --action=/proxy/https/docs.cloud.google.com/load-balancing/docs/tcp/allow \ --direction=ingress \ --source-ranges=SOURCE_RANGE \ --target-tags=load-balanced-backend \ --rules=tcp:80,tcp:443,tcp:8080
API
יוצרים את כלל חומת האש fw-ilb-to-backends על ידי שליחת בקשת POST ל-method firewalls.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-ilb-to-backends",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"allow-ssh"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"22"
]
}
],
"direction": "INGRESS"
}
יוצרים את כלל חומת האש fw-healthcheck על ידי שליחת בקשת POST ל-method firewalls.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-healthcheck",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"sourceRanges": [
"130.211.0.0/22",
"35.191.0.0/16"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp"
}
],
"direction": "INGRESS"
}
יוצרים את כלל חומת האש fw-backends כדי לאפשר תעבורת TCP בתת-רשת של ה-proxy עבור השיטה firewalls.insert. מחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls
{
"name": "fw-backends",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"sourceRanges": [
"10.129.0.0/23",
"10.130.0.0/23"
],
"targetTags": [
"load-balanced-backend"
],
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"80"
]
},
{
"IPProtocol": "tcp",
"ports": [
"443"
]
},
{
"IPProtocol": "tcp",
"ports": [
"8080"
]
}
],
"direction": "INGRESS"
}
יצירת קבוצות של מופעי מכונה מנוהלים
בקטע הזה נסביר איך ליצור תבנית וקבוצת מופעי מכונה מנוהלים. קבוצת מופעי מכונה מנוהלים מספקת מכונות וירטואליות שמריצות את שרתי הבק-אנד של מאזן עומסי רשת פנימי לשרת proxy חוצה אזורים לדוגמה. עבור קבוצת המופעים, אפשר להגדיר שירות HTTP ולמפות שם של יציאה ליציאה הרלוונטית. השירות לקצה העורפי של מאזן העומסים מעביר תנועה אל היציאות שצוינו. התנועה מלקוחות מאוזנת בעומס לשרתים בקצה העורפי. למטרות הדגמה, שרתי קצה עורפיים מציגים את שמות המארחים שלהם.
המסוף
נכנסים לדף Instance templates במסוף Google Cloud .
- לוחצים על Create instance template.
- בשדה Name (שם), מזינים
gil4-backendeast1-template. - מוודאים שדיסק האתחול מוגדר לקובץ אימג' של Debian, כמו Debian GNU/Linux 12 (bookworm). בהוראות האלה נעשה שימוש בפקודות שזמינות רק ב-Debian, כמו
apt-get. - לוחצים על אפשרויות מתקדמות.
- לוחצים על Networking ומגדירים את השדות הבאים:
- בשדה Network tags (תגי רשת), מזינים את הערכים
allow-sshו-load-balanced-backend. - בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
- רשת: NETWORK
- Subnet: SUBNET_B
- בשדה Network tags (תגי רשת), מזינים את הערכים
לוחצים על ניהול. מזינים את הסקריפט הבא בשדה סקריפט לטעינה בזמן ההפעלה.
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2
לוחצים על יצירה.
לוחצים על Create instance template.
בשדה Name (שם), מזינים
gil4-backendwest1-template.מוודאים שדיסק האתחול מוגדר לקובץ אימג' של Debian, כמו Debian GNU/Linux 12 (bookworm). בהוראות האלה נעשה שימוש בפקודות שזמינות רק ב-Debian, כמו
apt-get.לוחצים על אפשרויות מתקדמות.
לוחצים על Networking ומגדירים את השדות הבאים:
- בשדה Network tags (תגי רשת), מזינים את הערכים
allow-sshו-load-balanced-backend. - בקטע Network interfaces (ממשקי רשת), בוחרים באפשרויות הבאות:
- רשת: NETWORK
- Subnet: SUBNET_A
- בשדה Network tags (תגי רשת), מזינים את הערכים
לוחצים על ניהול. מזינים את הסקריפט הבא בשדה סקריפט לטעינה בזמן ההפעלה.
#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2
לוחצים על יצירה.
נכנסים לדף Instance groups במסוף Google Cloud .
- לוחצים על יצירת קבוצת מופעים.
- בוחרים באפשרות New managed instance group (stateless) (קבוצת מופעי מכונה מנוהלים חדשה (בלי שמירת מצב)). מידע נוסף מופיע במאמר קבוצות של מכונות וירטואליות בלי שמירת מצב או עם שמירת מצב.
- בשדה Name (שם), מזינים
gl4-ilb-miga. - בקטע מיקום, בוחרים באפשרות אזור יחיד.
- בשדה אזור, בוחרים באפשרות REGION_A.
- בשדה Zone, בוחרים באפשרות ZONE_A.
- בשדה תבנית של הגדרות מכונה, בוחרים באפשרות
gil4-backendwest1-template. מציינים את מספר המופעים שרוצים ליצור בקבוצה.
בדוגמה הזו, מציינים את האפשרויות הבאות בקטע התאמה אוטומטית לעומס:
- בקטע מצב שינוי גודל אוטומטי, בוחרים באפשרות
Off:do not autoscale. - בשדה מספר מופעים מקסימלי, מזינים
2.
אופציונלי: בקטע Autoscaling (שינוי גודל אוטומטי) בממשק המשתמש, אפשר להגדיר את קבוצת המופעים כך שמופעים יתווספו או יוסרו באופן אוטומטי בהתבסס על השימוש במעבד של המופע.
- בקטע מצב שינוי גודל אוטומטי, בוחרים באפשרות
לוחצים על יצירה.
לוחצים על יצירת קבוצת מופעים.
בוחרים באפשרות New managed instance group (stateless) (קבוצת מופעי מכונה מנוהלים חדשה (בלי שמירת מצב)). מידע נוסף מופיע במאמר קבוצות של מכונות וירטואליות בלי שמירת מצב או עם שמירת מצב.
בשדה Name (שם), מזינים
gl4-ilb-migb.בקטע מיקום, בוחרים באפשרות אזור יחיד.
בשדה אזור, בוחרים באפשרות REGION_B.
בשדה Zone, בוחרים באפשרות ZONE_B.
בשדה תבנית של הגדרות מכונה, בוחרים באפשרות
gil4-backendeast1-template.מציינים את מספר המופעים שרוצים ליצור בקבוצה.
בדוגמה הזו, מציינים את האפשרויות הבאות בקטע התאמה אוטומטית לעומס:
- בקטע מצב שינוי גודל אוטומטי, בוחרים באפשרות
Off:do not autoscale. - בשדה מספר מופעים מקסימלי, מזינים
2.
אופציונלי: בקטע Autoscaling (שינוי גודל אוטומטי) בממשק המשתמש, אפשר להגדיר את קבוצת המופעים כך שמופעים יתווספו או יוסרו באופן אוטומטי בהתבסס על השימוש במעבד של המופע.
- בקטע מצב שינוי גודל אוטומטי, בוחרים באפשרות
לוחצים על יצירה.
gcloud
ההוראות ל-CLI של gcloud במדריך הזה מבוססות על ההנחה שאתם משתמשים ב-Cloud Shell או בסביבה אחרת שבה מותקן bash.
יוצרים תבנית של הגדרות מכונה וירטואלית עם שרת HTTP באמצעות הפקודה
gcloud compute instance-templates create.gcloud compute instance-templates create gil4-backendwest1-template \ --region=REGION_A \ --network=NETWORK \ --subnet=SUBNET_A \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-12 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'gcloud compute instance-templates create gil4-backendeast1-template \ --region=REGION_B \ --network=NETWORK \ --subnet=SUBNET_B \ --tags=allow-ssh,load-balanced-backend \ --image-family=debian-12 \ --image-project=debian-cloud \ --metadata=startup-script='#! /bin/bash apt-get update apt-get install apache2 -y a2ensite default-ssl a2enmod ssl vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" echo "Page served from: $vm_hostname" | \ tee /var/www/html/index.html systemctl restart apache2'יוצרים קבוצת מופעי מכונה מנוהלים באזור באמצעות הפקודה
gcloud compute instance-groups managed create.gcloud compute instance-groups managed create gl4-ilb-miga \ --zone=ZONE_A \ --size=2 \ --template=gil4-backendwest1-templategcloud compute instance-groups managed create gl4-ilb-migb \ --zone=ZONE_B \ --size=2 \ --template=gil4-backendeast1-template
API
יוצרים את תבנית של הגדרות מכונה באמצעות השיטה instanceTemplates.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates
{
"name":"gil4-backendwest1-template",
"properties":{
"machineType":"e2-standard-2",
"tags":{
"items":[
"allow-ssh",
"load-balanced-backend"
]
},
"metadata":{
"kind":"compute#metadata",
"items":[
{
"key":"startup-script",
"value":"#! /bin/bash\napt-get update\napt-get install
apache2 -y\na2ensite default-ssl\na2enmod ssl\n
vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
\\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
echo \"Page served from: $vm_hostname\" | \\\ntee
/var/www/html/index.html\nsystemctl restart apache2"
}
]
},
"networkInterfaces":[
{
"network":"projects/PROJECT_ID/global/networks/NETWORK",
"subnetwork":"regions/REGION_A/subnetworks/SUBNET_A",
"accessConfigs":[
{
"type":"ONE_TO_ONE_NAT"
}
]
}
],
"disks":[
{
"index":0,
"boot":true,
"initializeParams":{
"sourceImage":"projects/debian-cloud/global/images/family/debian-12"
},
"autoDelete":true
}
]
}
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/instanceTemplates
{
"name":"gil4-backendeast1-template",
"properties":{
"machineType":"e2-standard-2",
"tags":{
"items":[
"allow-ssh",
"load-balanced-backend"
]
},
"metadata":{
"kind":"compute#metadata",
"items":[
{
"key":"startup-script",
"value":"#! /bin/bash\napt-get update\napt-get install
apache2 -y\na2ensite default-ssl\na2enmod ssl\n
vm_hostname=\"$(curl -H \"Metadata-Flavor:Google\"
\\\nhttp://169.254.169.254/computeMetadata/v1/instance/name)\"\n
echo \"Page served from: $vm_hostname\" | \\\ntee
/var/www/html/index.html\nsystemctl restart apache2"
}
]
},
"networkInterfaces":[
{
"network":"projects/PROJECT_ID/global/networks/NETWORK",
"subnetwork":"regions/REGION_B/subnetworks/SUBNET_B",
"accessConfigs":[
{
"type":"ONE_TO_ONE_NAT"
}
]
}
],
"disks":[
{
"index":0,
"boot":true,
"initializeParams":{
"sourceImage":"projects/debian-cloud/global/images/family/debian-12"
},
"autoDelete":true
}
]
}
}
יוצרים קבוצת מופעי מכונה מנוהלים בכל אזור באמצעות השיטה instanceGroupManagers.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers
{
"name": "gl4-ilb-miga",
"zone": "projects/PROJECT_ID/zones/ZONE_A",
"instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
"baseInstanceName": "gl4-ilb-miga",
"targetSize": 2
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/{zone}/instanceGroupManagers
{
"name": "gl4-ilb-migb",
"zone": "projects/PROJECT_ID/zones/ZONE_A",
"instanceTemplate": "projects/PROJECT_ID/global/instanceTemplates/gil4-backendwest1-template",
"baseInstanceName": "gl4-ilb-migb",
"targetSize": 2
}
הגדרת מאזן העומסים
בדוגמה הזו מוסבר איך ליצור את המשאבים הבאים של מאזן עומסי רשת פנימי לשרת proxy בין אזורים:
- בדיקת תקינות TCP גלובלית.
- שירות לקצה עורפי גלובלי עם אותן קבוצות MIG כמו הקצה העורפי.
- שרת proxy יעד גלובלי.
- שני כללי העברה גלובליים עם כתובות IP אזוריות.
לכתובת ה-IP של כלל ההעברה, משתמשים בטווח כתובות ה-IP
SUBNET_AאוSUBNET_B. אם מנסים להשתמש ברשת משנה מסוג proxy בלבד, יצירת כלל ההעברה נכשלת.
זמינות ה-Proxy
לפעמים Google Cloud באזורים מסוימים אין מספיק קיבולת של שרתי proxy למאזן עומסים חדש. במקרה כזה, כשיוצרים את איזון העומסים, מוצגת במסוף הודעת אזהרה לגבי זמינות ה-proxy. Google Cloud כדי לפתור את הבעיה, אפשר לבצע אחת מהפעולות הבאות:
- בוחרים אזור אחר למאזן העומסים. זו יכולה להיות אפשרות מעשית אם יש לכם שרתי בק-אנד באזור אחר.
- בוחרים רשת VPC שכבר הוקצתה לה רשת משנה רק לשרתי proxy.
צריך להמתין עד שהבעיה בקיבולת תיפתר.
המסוף
התחלת ההגדרה
נכנסים לדף Load balancing במסוף Google Cloud .
- לוחצים על Create load balancer (יצירת מאזן עומסים).
- בקטע Type of load balancer (סוג מאזן העומסים), בוחרים באפשרות Network Load Balancer (TCP/UDP/SSL) (מאזן עומסים ברשת (TCP/UDP/SSL)) ולוחצים על Next (הבא).
- בקטע Proxy or passthrough (פרוקסי או העברה), בוחרים באפשרות Proxy load balancer (מאזן עומסים של פרוקסי) ולוחצים על Next (הבא).
- בקטע Public facing or internal (פנימי או גלוי לכולם), בוחרים באפשרות Internal (פנימי) ולוחצים על Next (הבא).
- בקטע פריסה חוצה אזורים או פריסה באזור יחיד, בוחרים באפשרות הכי מתאים לעומסי עבודה חוצי אזורים ולוחצים על הבא.
- לוחצים על Configure (הגדרה).
הגדרה בסיסית
- מזינים שם למאזן העומסים.
- בקטע רשת, בוחרים באפשרות NETWORK.
הגדרת הקצה הקדמי עם שני כללי העברה
- לוחצים על Frontend configuration.
- מזינים שם לכלל ההעברה.
- ברשימה Subnetwork region, בוחרים באפשרות REGION_A.
שמירת תת-רשת של שרת proxy בלבד
- ברשימה Subnetwork, בוחרים באפשרות SUBNET_A.
- ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.
- מזינים שם לכתובת ה-IP הסטטית.
- ברשימה Static IP address בוחרים באפשרות Let me choose.
- בשדה כתובת IP מותאמת אישית, מזינים
10.1.2.99. - לוחצים על הזמנה.
- לוחצים על סיום.
- כדי להוסיף את כלל ההעברה השני, לוחצים על הוספת כתובת IP ופורט של קצה קדמי.
- מזינים שם לכלל ההעברה.
- ברשימה Subnetwork region, בוחרים באפשרות REGION_B.
שמירת תת-רשת של שרת proxy בלבד
- ברשימה Subnetwork, בוחרים באפשרות SUBNET_B.
- ברשימה IP address, לוחצים על Create IP address. ייפתח הדף שמירת כתובת IP פנימית סטטית.
- מזינים שם לכתובת ה-IP הסטטית.
- ברשימה Static IP address בוחרים באפשרות Let me choose.
- בשדה כתובת IP מותאמת אישית, מזינים
10.1.3.99. - לוחצים על הזמנה.
- לוחצים על סיום.
- לוחצים על Backend configuration.
- ברשימה Create or select backend services לוחצים על Create a backend service.
- מזינים שם לשירות הקצה העורפי.
- בשדה Protocol, בוחרים באפשרות TCP.
- בשדה Named Port (יציאה עם שם), מזינים
http. - ברשימה Backend type (סוג ה-Backend), בוחרים באפשרות Instance group (קבוצת מכונות).
- ברשימה בדיקת תקינות, לוחצים על יצירת בדיקת תקינות ומזינים את הפרטים הבאים:
- בשדה שם מזינים
global-http-health-check. - ברשימה Protocol, בוחרים באפשרות
HTTP. - בשדה יציאה, מזינים
80. - לוחצים על יצירה.
- בקטע New backend:
- ברשימה Instance group בוחרים באפשרות
gl4-ilb-migain REGION_A. - מגדירים את ניוד מספרים ל-
80. - בקטע מצב איזון, בוחרים באפשרות Connection.
- לוחצים על סיום.
- כדי להוסיף עוד שרת עורפי, לוחצים על הוספת שרת עורפי.
- ברשימה Instance group בוחרים באפשרות
gl4-ilb-migbב-REGION_B. - מגדירים את ניוד מספרים ל-
80. - לוחצים על סיום.
בדיקת ההגדרות
- לוחצים על Review and finalize.
- בודקים את הגדרות ההגדרה של מאזן העומסים.
- לוחצים על יצירה.
gcloud
מגדירים את בדיקת התקינות של TCP באמצעות הפקודה
gcloud compute health-checks create tcp.gcloud compute health-checks create tcp global-health-check \ --use-serving-port \ --global
מגדירים את שירות לקצה העורפי באמצעות הפקודה
gcloud compute backend-services create.gcloud compute backend-services create gl4-gilb-backend-service \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=TCP \ --enable-logging \ --logging-sample-rate=1.0 \ --health-checks=global-health-check \ --global-health-checks \ --global
מוסיפים קצה עורפי לשירות הקצה העורפי באמצעות הפקודה
gcloud compute backend-services add-backend.gcloud compute backend-services add-backend gl4-gilb-backend-service \ --balancing-mode=CONNECTION \ --max-connections=50 \ --instance-group=gl4-ilb-miga \ --instance-group-zone=ZONE_A \ --global
gcloud compute backend-services add-backend gl4-gilb-backend-service \ --balancing-mode=CONNECTION \ --max-connections=50 \ --instance-group=gl4-ilb-migb \ --instance-group-zone=ZONE_B \ --global
יוצרים את שרת ה-proxy של היעד.
יוצרים את שרת ה-proxy של היעד באמצעות הפקודה
gcloud compute target-tcp-proxies create.gcloud compute target-tcp-proxies create gilb-tcp-proxy \ --backend-service=gl4-gilb-backend-service \ --global
יוצרים שני כללי העברה, אחד עם כתובת VIP (10.1.2.99) ב-
REGION_Bואחד עם כתובת VIP (10.1.3.99) ב-REGION_A. מידע נוסף זמין במאמר בנושא שמירת כתובת IPv4 פנימית סטטית.ברשתות מותאמות אישית, צריך להפנות לרשת המשנה בכלל ההעברה. שימו לב: מדובר ברשת המשנה של המכונה הווירטואלית, ולא ברשת המשנה של ה-proxy.
משתמשים בפקודה
gcloud compute forwarding-rules createעם הדגלים המתאימים.gcloud compute forwarding-rules create gil4forwarding-rule-a \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_A \ --subnet-region=REGION_A \ --address=10.1.2.99 \ --ports=80 \ --target-tcp-proxy=gilb-tcp-proxy \ --global
gcloud compute forwarding-rules create gil4forwarding-rule-b \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=NETWORK \ --subnet=SUBNET_B \ --subnet-region=REGION_B \ --address=10.1.3.99 \ --ports=80 \ --target-tcp-proxy=gilb-tcp-proxy \ --global
API
כדי ליצור את בדיקת תקינות, שולחים בקשת POST אל ה-method healthChecks.insert ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/healthChecks
{
"name": "global-health-check",
"type": "TCP",
"httpHealthCheck": {
"portSpecification": "USE_SERVING_PORT"
}
}
יוצרים את שירות הלקצה העורפי הגלובלי על ידי שליחת בקשת POST ל-method backendServices.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/backendServices
{
"name": "gl4-gilb-backend-service",
"backends": [
{
"group": "projects/PROJECT_ID/zones/ZONE_A/instanceGroups/gl4-ilb-miga",
"balancingMode": "CONNECTION"
},
{
"group": "projects/PROJECT_ID/zones/ZONE_B/instanceGroups/gl4-ilb-migb",
"balancingMode": "CONNECTION"
}
],
"healthChecks": [
"projects/PROJECT_ID/regions/global/healthChecks/global-health-check"
],
"loadBalancingScheme": "INTERNAL_MANAGED"
}
יוצרים את שרת ה-TCP Proxy ביעד על ידי שליחת בקשת POST ל-method targetTcpProxies.insert, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/targetTcpProxy
{
"name": "l4-ilb-proxy",
}
שולחים בקשת POST ל-method forwardingRules.insert כדי ליצור את כלל ההעברה, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules
{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules
{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
שולחים בקשת POST ל-method globalForwardingRules.insert כדי ליצור את כלל ההעברה, ומחליפים את PROJECT_ID במזהה הפרויקט.
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules
{
"name": "gil4forwarding-rule-a",
"IPAddress": "10.1.2.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_A/subnetworks/SUBNET_A",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/forwardingRules
{
"name": "gil4forwarding-rule-b",
"IPAddress": "10.1.3.99",
"IPProtocol": "TCP",
"portRange": "80-80",
"target": "projects/PROJECT_ID/global/targetTcpProxies/l4-ilb-proxy",
"loadBalancingScheme": "INTERNAL_MANAGED",
"subnetwork": "projects/PROJECT_ID/regions/REGION_B/subnetworks/SUBNET_B",
"network": "projects/PROJECT_ID/global/networks/NETWORK",
"networkTier": "PREMIUM"
}
בדיקת מאזן העומסים
יצירת מכונת VM לבדיקת הקישוריות
יצירת מכונה וירטואלית (VM) של לקוח באזורים
REGION_Bו-REGION_A:gcloud compute instances create l4-ilb-client-a \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=NETWORK \ --subnet=SUBNET_A \ --zone=ZONE_A \ --tags=allow-sshgcloud compute instances create l4-ilb-client-b \ --image-family=debian-12 \ --image-project=debian-cloud \ --network=NETWORK \ --subnet=SUBNET_B \ --zone=ZONE_B \ --tags=allow-sshמשתמשים ב-SSH כדי להתחבר לכל מופע לקוח.
gcloud compute ssh l4-ilb-client-a --zone=ZONE_A
gcloud compute ssh l4-ilb-client-b --zone=ZONE_B
אימות כתובת ה-IP שמשרתת את שם המארח
מוודאים שהמכונה הווירטואלית של הלקוח יכולה להגיע לשתי כתובות ה-IP. הפקודה אמורה להצליח ולהחזיר את השם של מכונת ה-VM בעורף המערכת שטיפלה בבקשה:
curl 10.1.2.99
curl 10.1.3.99
בדיקת מעבר לגיבוי (failover)
לוודא שמתבצע מעבר לגיבוי (failover) לשרתי קצה בעורף באזור
REGION_Aכששרתי קצה בעורף באזורREGION_Bלא תקינים או לא נגישים. כדי לדמות יתירות כשל, מסירים את כל השרתים העורפיים מ-REGION_B:gcloud compute backend-services remove-backend gl4-gilb-backend-service \ --instance-group=gl4-ilb-migb \ --instance-group-zone=ZONE_B \ --global
מתחברים באמצעות SSH למכונה וירטואלית של לקוח ב-
REGION_B.gcloud compute ssh l4-ilb-client-b \ --zone=ZONE_B
שולחים בקשות לכתובת ה-IP של מאזן העומסים באזור
REGION_B. פלט הפקודה מציג תשובות ממכונות וירטואליות בעורף המערכת ב-REGION_A:{ RESULTS= for i in {1..100} do RESULTS="$RESULTS:$(curl 10.1.3.99)" done echo "***" echo "*** Results of load-balancing to 10.1.3.99: " echo "***" echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c echo }
אפשרויות הגדרה נוספות
בקטע הזה אנחנו מרחיבים את דוגמת ההגדרה ומציגים אפשרויות הגדרה חלופיות ונוספות. כל המשימות הן אופציונליות. אפשר לבצע אותן בכל סדר.
פרוטוקול PROXY לשמירת פרטי החיבור של הלקוח
מאזן העומסים הפנימי לשרת proxy מסיים חיבורי TCP מהלקוח ויוצר חיבורים חדשים למכונות הווירטואליות. כברירת מחדל, המידע המקורי על כתובת ה-IP והיציאה של הלקוח לא נשמר.
כדי לשמור את פרטי החיבור המקוריים ולשלוח אותם למופעים, צריך להפעיל את פרוטוקול ה-PROXY (גרסה 1). הפרוטוקול הזה שולח כותרת נוספת שמכילה את כתובת ה-IP של המקור, כתובת ה-IP של היעד ומספרי היציאות למופע כחלק מהבקשה.
מוודאים שמופעלים במופעי ה-Backend של מאזן העומסים הפנימי מסוג Network שרתי HTTP או HTTPS שתומכים בכותרות של פרוטוקול PROXY. אם שרתי ה-HTTP או ה-HTTPS לא מוגדרים לתמיכה בכותרות של פרוטוקול PROXY, המופעים העורפיים מחזירים תגובות ריקות. לדוגמה, פרוטוקול ה-PROXY לא פועל עם תוכנת Apache HTTP Server. אפשר להשתמש בתוכנות שרת אינטרנט שונות, כמו Nginx.
אם מגדירים את פרוטוקול ה-PROXY לתנועת משתמשים, צריך להגדיר אותו גם לבדיקות התקינות. אם אתם בודקים את התקינות ומציגים תוכן באותה יציאה, צריך להגדיר את --proxy-header של בדיקת התקינות כך שיתאים להגדרה של מאזן העומסים.
כותרת פרוטוקול ה-PROXY היא בדרך כלל שורה אחת של טקסט שקריא למשתמש בפורמט הבא:
PROXY TCP4 <client IP> <load balancing IP> <source port> <dest port>\r\n
דוגמה לפרוטוקול PROXY:
PROXY TCP4 192.0.2.1 198.51.100.1 15221 110\r\n
בדוגמה שלמעלה, כתובת ה-IP של הלקוח היא 192.0.2.1, כתובת ה-IP של איזון העומסים היא 198.51.100.1, יציאת הלקוח היא 15221 ויציאת היעד היא 110.
במקרים שבהם כתובת ה-IP של הלקוח לא ידועה, מאזן העומסים יוצר כותרת של פרוטוקול PROXY בפורמט הבא:
PROXY UNKNOWN\r\n
עדכון כותרת פרוטוקול ה-PROXY עבור שרת proxy של TCP ביעד
הדוגמה להגדרת מאזן עומסים בדף הזה מראה איך להפעיל את כותרת פרוטוקול ה-PROXY בזמן יצירת מאזן עומסי רשת פנימי לשרת proxy. כדי לשנות את כותרת פרוטוקול ה-PROXY בשרת TCP Proxy קיים, פועלים לפי השלבים הבאים.
המסוף
נכנסים לדף Load balancing במסוף Google Cloud .
לוחצים על Edit (עריכה) עבור מאזן העומסים.
לוחצים על Frontend configuration.
משנים את הערך של השדה Proxy protocol (פרוטוקול שרת Proxy) ל-On (מופעל).
לוחצים על עדכון כדי לשמור את השינויים.
gcloud
בפקודה הבאה, עורכים את השדה --proxy-header ומגדירים אותו לערך NONE או PROXY_V1, בהתאם לדרישה.
gcloud compute target-ssl-proxies update int-tcp-target-proxy \
--proxy-header=[NONE | PROXY_V1]
שימוש באותה כתובת IP בכמה כללי העברה פנימיים
כדי שכמה כללי העברה פנימיים ישתמשו באותה כתובת IP פנימית, צריך לשמור את כתובת ה-IP ולהגדיר את הדגל --purpose שלה לערך SHARED_LOADBALANCER_VIP.
gcloud
gcloud compute addresses create SHARED_IP_ADDRESS_NAME \
--region=REGION \
--subnet=SUBNET_NAME \
--purpose=SHARED_LOADBALANCER_VIP
הפעלת זיקה לסשן
ההגדרה לדוגמה יוצרת שירות לקצה העורפי ללא זיקה לסשן (session affinity).
בקטעים הבאים מוסבר איך לעדכן שירות לקצה העורפי עבור מאזן עומסים לדוגמה, כך ששירות לקצה העורפי ישתמש בזיקה לכתובת IP של לקוח או בזיקה לקובץ Cookie שנוצר.
כשזיקה לכתובת IP של לקוח מופעלת, מאזן העומסים (LB) מפנה את הבקשות של לקוח מסוים לאותה מכונה וירטואלית (VM) בעורף, על סמך גיבוב שנוצר מכתובת ה-IP של הלקוח וכתובת ה-IP של מאזן העומסים (כתובת ה-IP הפנימית של כלל העברה פנימי).
המסוף
כדי להפעיל זיקה לסשן לפי כתובת IP של לקוח:
- נכנסים לדף Load balancing במסוף Google Cloud .
כניסה לדף איזון עומסים - לוחצים על Backends.
- לוחצים על השם של שירות לקצה העורפי שיצרתם בדוגמה הזו ואז על עריכה.
- בדף פרטי שירות לקצה העורפי, לוחצים על הגדרות מתקדמות.
- בקטע Session affinity, בוחרים באפשרות Client IP מהתפריט.
- לוחצים על עדכון.
gcloud
כדי לעדכן את BACKEND_SERVICEשירות לקצה העורפי ולציין את הזיקה לסשן (session affinity) לכתובת IP של לקוח, מריצים את הפקודה הבאה של gcloud:
gcloud compute backend-services update BACKEND_SERVICE \
--global \
--session-affinity=CLIENT_IP
הפעלת זמן להשלמת תהליך (connection draining)
אתם יכולים להפעיל זמן להשלמת תהליך (connection draining) בשירותי קצה עורפי כדי להבטיח הפרעה מינימלית למשתמשים כשמופסקת פעילות של מופע שמשרת תעבורה, כשמסירים אותו באופן ידני או כשמסירים אותו באמצעות מידרוג אוטומטי. מידע נוסף על זמן להשלמת תהליך (connection draining) זמין במאמרי עזרה בנושא הפעלת ניתוק חיבורים.
המאמרים הבאים
- המרת מאזן עומסי רשת לשרת proxy ל-IPv6
- סקירה כללית על מאזן עומסי רשת פנימי לשרת proxy
- תת-רשתות של שרת proxy בלבד למאזני עומסים מבוססי Envoy.
- לפנות הגדרת איזון עומסים