הרחבת Apigee למספר אזורים

הדף הזה מתייחס ל-Apigee, אבל לא ל-Apigee Hybrid.

לעיון במסמכי התיעוד של Apigee Edge

אפשר להרחיב ארגון של Apigee למספר אזורים. הרחבת האזורים מאפשרת שיפורים בתחומים הבאים:

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

במאמר הזה מוסבר איך להוסיף את Apigee לאזור חדש ואיך להסיר את Apigee מאזור.

הוספת Apigee לאזור חדש

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

התהליך הכללי להוספת אזור חדש הוא כזה:

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

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

דרישות מוקדמות

צריך לוודא שברשת שלכם יש טווחי כתובות IP זמינים שלא חופפים, /22 ו-/28. הטווח הזה הוא בנוסף לטווחים שמשמשים אזורים אחרים.

מגבלות

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

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

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

לא יכולים להיות יותר מ-10 אזורים בארגון (11 בארגון היברידי).

הגדרת משתני סביבה

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

export NEW_REGION_LOCATION="NEW_REGION_LOCATION"
export NEW_INSTANCE_NAME="NEW_INSTANCE_NAME"
export NETWORK_NAME"=NETWORK_NAME"
export DISK_KEY_RING_NAME="YOUR_DISK_KEY_RING_NAME"
export DISK_KEY_NAME="YOUR_DISK_KEY_NAME"
export PROJECT_ID=YOUR_PROJECT_ID
export AUTH="Authorization: Bearer $(gcloud auth print-access-token)"
export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID --format="value(projectNumber)")

כאשר:

‫NEW_REGION_LOCATION הוא המיקום הפיזי של המופע החדש. הערכים התקינים הם כל אזור של Compute Engine. מידע נוסף זמין במאמר אזורים ותחומים. לדוגמה, us-west1.
‫NEW_INSTANCE_NAME הוא שם האזור החדש. הוא חייב להיות ייחודי לארגון שלכם. לדוגמה, my-instance-2.
‫NETWORK_NAME הוא השם של רשת ה-Peering של הארגון. לדוגמה, my-network. מידע נוסף זמין במאמר בנושא הגדרת רשתות שירות.
‫DISK_KEY_RING_NAME הוא שם של אוסף מפתחות לדיסק.
‫DISK_KEY_NAME הוא שם של אוסף הדיסקים.
‫AUTH מגדיר את הכותרת Authentication עם אסימון Bearer. תשתמשו בכותרת הזו כשתיגשו לממשקי Apigee API. שימו לב שהאסימון יפוג אחרי פרק זמן מסוים, ואז תוכלו פשוט ליצור אותו מחדש באמצעות אותה פקודה. מידע נוסף זמין בדף העיון בנושא הפקודה print-access-token.
‫PROJECT_ID הוא מזהה הפרויקט בענן שלכם.
‫PROJECT_NUMBER הוא מספר הפרויקט בענן עבור פרויקט ה-Cloud שלך.

יצירת אוסף מפתחות ומפתח חדשים

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

פרטים נוספים זמינים במאמר מידע על מפתחות ההצפנה של Apigee.

כדי ליצור אוסף מפתחות ומפתח חדשים להצפנת דיסק:

יוצרים מחזיק מפתחות חדש לדיסק באמצעות הפקודה gcloud:

gcloud kms keyrings create $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

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

gcloud kms keyrings list \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

gcloud kms keyrings describe $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

יוצרים מפתח דיסק חדש באמצעות הפקודה kms keys create. לדוגמה:

gcloud kms keys create $DISK_KEY_NAME --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION --purpose "encryption" --project $PROJECT_ID

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

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

נתיב המפתח נראה כך:

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

כדי לתת לסוכן השירות של Apigee גישה לשימוש במפתח החדש, מריצים את הפקודה gcloud kms keys add-iam-policy-binding. לדוגמה:

gcloud kms keys add-iam-policy-binding $DISK_KEY_NAME \
  --location $NEW_REGION_LOCATION \
  --keyring $DISK_KEY_RING_NAME \
  --member serviceAccount:service-$PROJECT_NUMBER@gcp-sa-apigee.iam.gserviceaccount.com \
  --role roles/cloudkms.cryptoKeyEncrypterDecrypter \
  --project $PROJECT_ID

מוודאים שהמפתח משויך לסוכן השירות של Apigee.

gcloud kms keys get-iam-policy $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

gcloud kms keys describe $DISK_KEY_NAME \
  --keyring $DISK_KEY_RING_NAME \
  --location $NEW_REGION_LOCATION \
  --project $PROJECT_ID

שמירת טווח כתובות חדש

שמירת כתובות IP לטווח הכתובות של רשת הקישור בין רשתות שכנות (peering). מידע נוסף ושיקולים חשובים מפורטים גם במאמר הסבר על טווחי peering.

יוצרים את משתני הסביבה הבאים:
```
export NEW_RANGE_NAME_22=YOUR_CIDR_22_RANGE_NAME
export NEW_RANGE_NAME_28=YOUR_CIDR_28_RANGE_NAME
export NETWORK_NAME=YOUR_NETWORK_NAME
```
כאשר:
- ‫NEW_RANGE_NAME_22 הוא השם של טווח כתובות ה-IP באורך CIDR ‏‎ /22 שתיצרו. אפשר לתת לטווח כל שם שרוצים. לדוגמה: google-svcs-new_22
- ‫NEW_RANGE_NAME_28 הוא השם של טווח כתובות ה-IP באורך CIDR ‏‎ /28 שתצרו. אפשר לתת לטווח כל שם שרוצים. לדוגמה: google-svcs-new_28
- ‫NETWORK_NAME הוא שם משאב הרשת שבו צריך לשריין את הכתובות.
  ‫Google יוצרת רשת שמוגדרת כברירת מחדל (בשם default) לכל פרויקט חדש, כך שאפשר להשתמש בה. עם זאת, Google לא ממליצה להשתמש ברשת שמוגדרת כברירת מחדל לכל מטרה אחרת מלבד בדיקה.
  
  הערה: Google לא ממליצה להשתמש ב-default אלא אם אתם בודקים את תהליך ההגדרה הזה. אסור להשתמש בארגון עם רשת ברירת מחדל בסביבת ייצור.

יוצרים טווח כתובות IP ברשת עם אורך CIDR של ‎ /22:

gcloud compute addresses create $NEW_RANGE_NAME_22 \
  --global \
  --prefix-length=22 \
  --description="Peering range for Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID

אם הפעולה מצליחה, gcloud משיב עם:

Created [https://www.googleapis.com/compute/v1/projects/PROJECT_NAME/global/addresses/google-svcs-new].

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

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

gcloud compute addresses describe $NEW_RANGE_NAME_22 \
  --global \
  --project=$PROJECT_ID

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

יוצרים טווח כתובות IP ברשת עם אורך CIDR של ‎ /28. הטווח הזה נדרש ומשמש את Apigee למטרות פתרון בעיות. אי אפשר להתאים אותו אישית או לשנות אותו.
```
gcloud compute addresses create $NEW_RANGE_NAME_28 \
  --global \
  --prefix-length=28 \
  --description="Peering range for supporting Apigee services" \
  --network=$NETWORK_NAME \
  --purpose=VPC_PEERING \
  --project=$PROJECT_ID
```

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

gcloud compute addresses list \
  --global \
  --project=$PROJECT_ID

 gcloud compute addresses describe $NEW_RANGE_NAME_28 \
  --global \
  --project=$PROJECT_ID

אחזור השמות של טווחי הקישור בין רשתות שכנות (peering):
```
gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID
```
מוסיפים את טווחי הכתובות החדשים שהוזמנו לרשת המקושרת באמצעות הפקודה הבאה, כאשר $NEW_RANGE_NAME_22 ו-$NEW_RANGE_NAME_28 הם שמות הטווחים החדשים, ו-ORIGINAL_RANGE_NAME_1 ו-ORIGINAL_RANGE_NAME_n הם שמות טווחי הכתובות השמורים של הקישוריות שהוחזרו בפקודה הקודמת:
```
gcloud services vpc-peerings update --service=servicenetworking.googleapis.com \
  --network=$NETWORK_NAME \
  --ranges=$NEW_RANGE_NAME_22,$NEW_RANGE_NAME_28,ORIGINAL_RANGE_NAME_1,ORIGINAL_RANGE_NAME_n \
  --project=$PROJECT_ID
```

מאמתים את השינויים ב-VPC Peering שעדכנתם:

gcloud services vpc-peerings list \
  --network=$NETWORK_NAME \
  --project=$PROJECT_ID

יצירת מופע חדש

יוצרים מופע חדש לאזור באמצעות Instances API.

עם קישור בין רשתות VPC שכנות (peering)

אם Apigee הוגדר לשימוש בקישור בין רשתות VPC שכנות (peering), משתמשים בקריאה הזו ל-API כדי ליצור את המופע:

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$NEW_INSTANCE_NAME"'",
    "location":"'"$NEW_REGION_LOCATION"'",
    "diskEncryptionKeyName":"KEY_PATH",
    "ipRange":"IP_ADDRESS_1/28, IP_ADDRESS_2/22"  # OPTIONAL
  }'

כאשר:

‫KEY_PATH הוא נתיב המפתח של מפתח ההצפנה של הדיסק שיצרתם במאמר יצירה של אוסף מפתחות ומפתח.
‫IP_ADDRESS_* הן כתובות IP בסימון CIDR לטווחים /22 ו-/28 של CIDR שמשמשים ליצירת מופע Apigee. הערך ipRange הוא אופציונלי. אם לא תציינו את השדה הזה, Apigee יבקש באופן אוטומטי בלוק CIDR זמין של ‎ /22 ו-‎ /28 מ-Service Networking. אפשר גם לעיין ב-Apigee instances API.

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

ללא VPC-peering

אם לא הגדרתם את Apigee לשימוש ב-VPC Peering, אתם יכולים להשתמש בקריאה הזו ל-API כדי ליצור את המופע:

curl -X POST -H "$AUTH" \
  -H "Content-Type:application/json" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances" \
  -d '{
    "name":"'"$INSTANCE_NAME"'",
    "location":"'"$RUNTIME_LOCATION"'",
    "diskEncryptionKeyName":"'"KEY_PATH"'",
    "consumerAcceptList":[ARRAY_OF_PROJECT_IDS]
  }'

כאשר:

‫KEY_PATH הוא נתיב המפתח של מפתח ההצפנה של הדיסק שיצרתם במאמר יצירה של אוסף מפתחות ומפתח. אפשר גם לעיין ב-Apigee instances API.
‫consumerAcceptList(אופציונלי) מציין רשימה של מזהי פרויקטים ב-Google Cloud שיכולים להתחבר באופן פרטי לשירות המצורף של ה-VPC של Apigee. ‫Service attachment הוא ישות שמשמשת עם Private Service Connect של Google Cloud כדי לאפשר ליצרני שירותים (במקרה הזה, Apigee) לחשוף שירותים לצרכנים (במקרה הזה, פרויקט אחד או יותר ב-Cloud שבבעלותכם). כברירת מחדל, אנחנו משתמשים בפרויקט ב-Cloud שכבר משויך לארגון שלכם ב-Apigee. לדוגמה: "consumerAcceptList": ["project1", "project2", "project3"]

איך מוצאים את נתיב המפתח

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

gcloud kms keys list \
  --location=$NEW_REGION_LOCATION \
  --keyring=$DISK_KEY_RING_NAME \
  --project=$PROJECT_ID

נתיב המפתח נראה כך:

projects/PROJECT_ID/locations/NEW_REGION_LOCATION/keyRings/my-disk-key-ring/cryptoKeys/my-disk-key

טיימר פעולת יצירת המופע נמשכת כ-30 דקות.

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

curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME"

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

צירוף סביבות למופע החדש

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

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

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

כדי לצרף את הסביבות לאזור החדש, משתמשים ב-Instances attachment API כמו בדוגמה הבאה:

curl -X POST -H "$AUTH" \
  -H "Content-Type: application/json" \
  https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances/$NEW_INSTANCE_NAME/attachments \
  -d '{
    "environment":"ENVIRONMENT_NAME"
  }'

כדי לקבל רשימה של הסביבות:

curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/environments"

צריך לצרף כל סביבה באמצעות קריאה נפרדת ל-Instances Attachment API. אי אפשר לצרף יותר מסביבה אחת לשיחה אחת.

הגדרת ניתוב

אפשר להגדיר ניתוב רשת באזור החדש באמצעות קבוצת מופעי מכונה מנוהלים (MIG) או הגדרה שמבוססת על Private Service Connect.

הגדרת ניתוב של Private Service Connect

בשלבים הבאים מוסבר איך להגדיר ניתוב באזור החדש באמצעות Private Service Connect.

סקירה כללית

באיור הבא מוצגת ארכיטקטורה כללית של Private Service Connect במספר אזורים:

דיאגרמה של ניתוב Private Service Connect בכמה אזורים.

איור 1: ארכיטקטורה של מספר אזורים עם Private Service Connect

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

(אופציונלי) בדיקה באמצעות מאזן עומסים זמני

לפני שממשיכים, כדאי לבדוק את המכונה החדשה על ידי הגדרה של איזון עומסים (LB) ו-NEG זמניים כדי לתקשר עם Apigee באזור החדש. אחרי ששולחים בהצלחה תנועת API למאזן העומסים לבדיקה, אפשר למחוק את מאזן העומסים הזמני ולחבר את ה-NEG לשירות לקצה העורפי של מאזן העומסים של Apigee בסביבת הייצור.

כדי לבדוק את המופע החדש:

פועלים לפי כל השלבים בנושא ניתוב חיצוני (Private Service Connect) שבשלב 8: הגדרת ניתוב כדי להקצות מאזן עומסים גלובלי מקביל באזור החדש. השלבים האלה כוללים יצירה של NEG חדש והוספה שלו לשירות לקצה העורפי של LB זמני.
בודקים proxy ל-API מלקוח חיצוני. כדי לבדוק ניתוב חיצוני, אפשר לעיין במאמר בנושא פריסת שרת proxy לדוגמה.
כשמסיימים את הבדיקה, מוחקים את מאזן העומסים הזמני. שימו לב: אין צורך למחוק את ה-NEG. אפשר להשתמש בו שוב, כמו שמוסבר בהמשך. איך מנקים הגדרות של איזון עומסים

יצירת קבוצת נקודות קצה ברשת עבור האזור החדש

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

יוצרים NEG חדש:
הערה: אם לא מחקתם את ה-NEG שיצרתם במהלך הבדיקה, אתם יכולים להשתמש בו שוב. במקרה כזה, דלגו על השלב הזה ועברו לשלב 2.
1. מקבלים את קובץ השירות מהמכונה שיצרתם קודם:
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
  בדוגמת הפלט הבאה, הערך serviceAttachment מוצג בטקסט מודגש:
```
{
  "instances": [
    {
      "name": "us-west1",
      "location": "us-west1",
      "host": "10.82.192.2",
      "port": "443",
      "createdAt": "1645731488019",
      "lastModifiedAt": "1646504754219",
      "diskEncryptionKeyName": "projects/my-project/locations/us-west1/keyRings/us-west1/cryptoKeys/dek",
      "state": "ACTIVE",
      "peeringCidrRange": "SLASH_22",
      "runtimeVersion": "1-7-0-20220228-190814",
      "ipRange": "10.82.192.0/22,10.82.196.0/28",
      "consumerAcceptList": [
        "875609189304"
      ],
      "serviceAttachment": "projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7"
    }
  ]
}
```
  הערה: המזהה של הפרויקט שבו השתמשתם כדי ליצור את הארגון שלכם ב-Apigee תמיד מופיע ברשימה consumerAcceptList. בדוגמה של הפלט שמוצגת למעלה, זה הפרויקט היחיד ברשימה.
2. יוצרים NEG שמפנה ל-Service Attachment שקיבלתם מגוף התגובה של המופע בשלב הקודם.
```
gcloud compute network-endpoint-groups create NEG_NAME \
  --network-endpoint-type=private-service-connect \
  --psc-target-service=TARGET_SERVICE \
  --region=$NEW_REGION_LOCATION \
  --network=NETWORK_NAME \
  --subnet=SUBNET_NAME \
  --project=PROJECT_ID
```
  מחליפים את מה שכתוב בשדות הבאים:
  - ‫NEG_NAME: שם לקבוצת נקודות הקצה ברשת.
  - ‫TARGET_SERVICE: קובץ השירות שאליו רוצים להתחבר. לדוגמה: projects/bfac7497a40c32a12p-tp/regions/us-west1/serviceAttachments/apigee-us-west1-crw7
  - ‫NETWORK_NAME: (אופציונלי) שם הרשת שבה נוצר ה-NEG. אם לא מציינים את הפרמטר הזה, נעשה שימוש ברשת של פרויקט default.
  - ‫SUBNET_NAME: השם של תת-הרשת שמשמשת לקישוריות פרטית אל היצרן. גודל תת-הרשת יכול להיות קטן: ה-NEG של Private Service Connect צריך רק כתובת IP אחת מתת-הרשת. ב-Apigee, נדרש רק NEG אחד של Private Service Connect לכל אזור. אפשר לשתף את רשת המשנה ולהשתמש בה במכונות וירטואליות או בישויות אחרות. אם לא מציינים רשת משנה, יכול להיות שנקודות קצה ברשת ישתייכו לכל רשת משנה באזור שבו נוצרה קבוצת נקודות הקצה ברשת.
    הערה: אם מציינים את הפרמטר --network,צריך לציין גם את הפרמטר --subnet.
  - PROJECT_ID פרויקט בענן שכבר משויך לארגון Apigee, או פרויקט בענן שנכלל ב-consumerAcceptlist כשנוצר מופע זמן הריצה של Apigee.
מקבלים את השם של שירות הקצה העורפי של מאזן העומסים של Apigee בסביבת הייצור:
```
gcloud compute backend-services list --project=$PROJECT_ID
```
מוסיפים את ה-NEG כקצה העורפי לשירות הקצה העורפי:
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --network-endpoint-group=NEG_NAME \
  --network-endpoint-group-region=$NEW_REGION_LOCATION \
  --global --project=$PROJECT_ID
```
מחליפים את מה שכתוב בשדות הבאים:
- ‫BACKEND_SERVICE_NAME: השם של שירות הקצה העורפי.
- ‫NEG_NAME: השם של קבוצת נקודות הקצה ברשת.
(אופציונלי) אפשר להגדיר מדיניות תנועה לזיהוי חריגות בשירות לקצה העורפי כדי לטפל בתרחישי יתירות כשל אוטומטיים. מידע נוסף זמין במאמרים הבאים:

בדיקת ההגדרה הסופית

שליחת קריאה ל-proxy ל-API. כך פורסים שרת proxy לדוגמה.

הגדרת ניתוב של MIG

בשלבים הבאים מוסבר איך להגדיר ניתוב באזור החדש באמצעות קבוצת מופעים מנוהלת (MIG).

סקירה כללית

האיור הבא מציג את הארכיטקטורה הכללית של תנועה צפונה במספר אזורים באמצעות קבוצות של מכונות וירטואליות לניהול (MIG):

תרשים של ארכיטקטורה צפונית ל-Private Service Connect במספר אזורים.

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

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

(אופציונלי) בדיקה באמצעות מאזן עומסים זמני

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

כדי לבדוק את המופע החדש:

פועלים לפי כל השלבים של ניתוב חיצוני (MIG) בשלב 8: הגדרת ניתוב כדי להקצות מאזן עומסים גלובלי מקביל באזור החדש.
בודקים proxy ל-API מלקוח חיצוני. כדי לבדוק ניתוב חיצוני, אפשר לעיין במאמר בנושא פריסת שרת proxy לדוגמה.
כשמסיימים את הבדיקה, מוחקים את מאזן העומסים הזמני. שימו לב: לא צריך למחוק את ה-MIG. אפשר להשתמש בו שוב, כמו שמוסבר בהמשך. איך מנקים הגדרות של איזון עומסים

יצירת קבוצת מופעי מכונה מנוהלים (MIG) לאזור החדש

כדי ליצור ולהגדיר קבוצת MIG לאזור החדש:

מפעילים גישה פרטית ל-Google ברשת משנה של רשת ה-VPC.

כדי להפעיל גישה פרטית ל-Google עבור רשת משנה של רשת ה-VPC, פועלים לפי השלבים שמפורטים במאמר הפעלת גישה פרטית ל-Google.
מגדירים משתני סביבה:

ההוראות בקטע הזה משתמשות במשתני סביבה כדי להתייחס למחרוזות שחוזרות על עצמן. מומלץ להגדיר את ההגדרות האלה לפני שממשיכים:
```
MIG_NAME=YOUR_MIG_NAME
VPC_NAME=YOUR_VPC_NAME       # If you are using a shared VPC, use the shared VPC name
VPC_SUBNET=YOUR_SUBNET_NAME     # Private Google Access must be enabled for this subnet
NEW_REGION_LOCATION=YOUR_NEW_REGION      # The same region as your new Apigee runtime instance
APIGEE_ENDPOINT=APIGEE_INSTANCE_IP        # See the tip below for details on getting this IP address value
```
הערה: כדי לקבל את כתובת ה-IP הנכונה של מופע Apigee, צריך להשתמש ב-Instances API, כמו בדוגמה הבאה:
```
curl -i -X GET -H "$AUTH" \
  "https://apigee.googleapis.com/v1/organizations/$PROJECT_ID/instances"
```
‫Apigee משיב עם פרטים על המופע. לדוגמה:
```
{
  "instances": [
    {
      "name": "my-runtime-instance",
      "location": "us-west1",
      "host": "10.16.0.2",
      "port": "443"
    },
    ...
  ]
}
```
כתובת ה-IP של המכונה, שאפשר להקצות למשתנה הסביבה $APIGEE_ENDPOINT, היא הערך של השדה host. בדוגמה הזו, הערך הוא 10.16.0.2.

בהתקנה עם מספר אזורים, קריאה ל-API מחזירה פרטי מופע לכל מיקום אזורי.
יוצרים קבוצה של מופעי מכונה מנוהלים. בשלב הזה, יוצרים ומגדירים קבוצה של מופעי מכונה מנוהלים (MIG).
הערה: אם לא מחקתם את קבוצת ה-MIG שיצרתם במהלך הבדיקה, תוכלו להשתמש בה שוב. במקרה כזה, מדלגים על השלב הזה ועוברים לשלב 3.
1. מריצים את הפקודה הבאה כדי ליצור תבנית של הגדרות מכונה.
```
gcloud compute instance-templates create $MIG_NAME \
  --project $PROJECT_ID \
  --region $NEW_REGION_LOCATION \
  --network $VPC_NAME \
  --subnet $VPC_SUBNET \
  --tags=https-server,apigee-mig-proxy,gke-apigee-proxy \
  --machine-type e2-medium --image-family debian-12 \
  --image-project debian-cloud --boot-disk-size 20GB \
  --no-address \
  --metadata ENDPOINT=$APIGEE_ENDPOINT,startup-script-url=gs://apigee-5g-saas/apigee-envoy-proxy-release/latest/conf/startup-script.sh
```
  כמו שאפשר לראות מהפקודה הזו, המכונות הן מסוג e2-medium. הם מריצים Debian 12 ויש להם 20GB של דיסק. סקריפט startup-script.sh מגדיר את ה-MIG לניתוב תעבורה נכנסת ממאזן העומסים למופע Apigee.
2. כדי ליצור קבוצת מופעי מכונה מנוהלים, מריצים את הפקודה הבאה:
```
gcloud compute instance-groups managed create $MIG_NAME \
  --project $PROJECT_ID --base-instance-name apigee-mig \
  --size 2 --template $MIG_NAME --region $NEW_REGION_LOCATION
```
3. מגדירים התאמה אוטומטית לעומס לקבוצה על ידי הפעלת הפקודה הבאה:
  הערה: קבוצת MIG אזורית עם מופעי e2-medium יכולה לתמוך במהירות מקסימלית של 6Gbps. אם זה לא מספיק לצרכי התפוקה שלכם, כדאי להגדיל את גודל המכונה הווירטואלית או להגדיל את מספר העותקים.
```
gcloud compute instance-groups managed set-autoscaling $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --max-num-replicas 3 \
  --target-cpu-utilization 0.75 --cool-down-period 90
```
4. מגדירים יציאה עם שם באמצעות הפעלת הפקודה הבאה:
```
gcloud compute instance-groups managed set-named-ports $MIG_NAME \
  --project $PROJECT_ID --region $NEW_REGION_LOCATION --named-ports https:443
```
מקבלים את השם של שירות הקצה העורפי של מאזן העומסים של Apigee בסביבת הייצור:
```
gcloud compute backend-services list --project=$PROJECT_ID
```
מוסיפים את ה-MIG לשירות הקצה העורפי באמצעות הפקודה הבאה:
```
gcloud compute backend-services add-backend BACKEND_SERVICE_NAME \
  --project $PROJECT_ID --instance-group $MIG_NAME \
  --instance-group-region $NEW_REGION_LOCATION \
  --balancing-mode UTILIZATION --max-utilization 0.8 --global
```
מחליפים את BACKEND_SERVICE_NAME בשם של שירות ה-Backend.

הערה: חשוב לוודא שבדיקת התקינות של מאזן העומסים מוגדרת כמו שמתואר במאמר הקצאת ארגון בתשלום עם קישור בין רשתות שכנות (peering) של VPC: שלב 8e 'יצירת מאזן עומסים גלובלי', שלב משנה 1 'יצירת בדיקת תקינות'.

בדיקת ההגדרה הסופית

שליחת קריאה ל-proxy ל-API. כך פורסים שרת proxy לדוגמה.

הוספת אזורים

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

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

בפריסה פעילה-פעילה בכמה אזורים, התעבורה מוגשת משני אזורים בו-זמנית. מוסיפים שירות קצה עורפי לכל אזור MIG לאותו מאזן עומסים חיצוני מסוג HTTPS ‏(XLB), כמו שמוסבר בשלב 8e(3) בכרטיסייה External routing (MIG) (ניתוב חיצוני (MIG)) בקטע Step 8: Configure routing (שלב 8: הגדרת ניתוב). מידע נוסף זמין גם במאמר בנושא יצירה של קבוצת מופעי מכונה מנוהלים (MIG) לאזור החדש.

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

הוספת אזורים לחיוב לפי שימוש

במודל התמחור Pay-as-you-go, אפשר להגדיר את המספר המינימלי של צמתי שער Apigee לסביבה. כך אפשר לוודא שבאזורים תמיד תהיה קיבולת נוספת כדי לתמוך באופן מיידי בתעבורת יתירות כשל, במקרה של כשל באזור.

הגדרת המספר המינימלי של צמתי שער Apigee

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

עלות

בדוגמה שלמעלה, העלות שתחויבו עליה היא העלות של הפעלת לפחות 16 צמתים של שער Apigee (8 צמתים x 2 אזורים). העלות עשויה לגדול ככל שמספר הצמתים גדל באופן אוטומטי כדי לטפל בתנועה נוספת, עד למקסימום.

הסרת Apigee מאזור

כדי להוציא משימוש מופע של Apigee ולהפסיק את התעבורה של API דרכו, צריך לבצע את השלבים הבאים כדי להבטיח שירות ללא הפרעות (אפס זמן השבתה לממשקי ה-API):

מפעילים connection draining בשירות לקצה העורפי. זמן להשלמת תהליך (connection draining) הוא תהליך שמבטיח שיינתן זמן להשלמת בקשות קיימות שנמצאות בתהליך, כשמסירים בק-אנד משירות לקצה העורפי.
אם Cloud DNS הוגדר להפניית התנועה לאזור Apigee הזה דרך מדיניות ההפניה האוטומטית של round-robin משוקלל, צריך להסיר את הגדרת ה-DNS הזו, כמו שמתואר במאמר ניהול מדיניות הפניה אוטומטית של DNS ובדיקות תקינות.
מנתקים את הקצה העורפי של ה-MIG משירות הקצה העורפי. הפעולה הזו, יחד עם זמן להשלמת תהליך (connection draining), תבטיח שמופע Apigee לא יקבל תנועה חדשה, אבל תאפשר להשלים בקשות שנמצאות בתהליך.
מוחקים את מופע Apigee ואת ה-MIG התואם. כך מוחקים מכונה.

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

הוספת Apigee לאזור חדש

דרישות מוקדמות

מגבלות

הגדרת משתני סביבה

יצירת אוסף מפתחות ומפתח חדשים

שמירת טווח כתובות חדש

יצירת מופע חדש

עם קישור בין רשתות VPC שכנות (peering)

ללא VPC-peering

איך מוצאים את נתיב המפתח

צירוף סביבות למופע החדש

הגדרת ניתוב

הגדרת ניתוב של Private Service Connect

סקירה כללית

(אופציונלי) בדיקה באמצעות מאזן עומסים זמני

יצירת קבוצת נקודות קצה ברשת עבור האזור החדש

בדיקת ההגדרה הסופית

הגדרת ניתוב של MIG

סקירה כללית

(אופציונלי) בדיקה באמצעות מאזן עומסים זמני

יצירת קבוצת מופעי מכונה מנוהלים (MIG) לאזור החדש

בדיקת ההגדרה הסופית

הוספת אזורים

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

הוספת אזורים לחיוב לפי שימוש

הגדרת המספר המינימלי של צמתי שער Apigee

עלות

הסרת Apigee מאזור

הרחבת Apigee למספר אזורים