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

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

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

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

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

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

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

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

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

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

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

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

מוודאים שיש ברשת טווחי כתובות 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 הוא מספר הפרויקט בענן שלכם.

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

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

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

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

1. יוצרים מחזיק מפתחות חדש לדיסק באמצעות הפקודה 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

2. יוצרים מפתח דיסק חדש באמצעות הפקודה 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

3. כדי לתת לסוכן השירות של 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.

1. יוצרים את משתני הסביבה הבאים:

   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 לא ממליצה להשתמש ברשת שמוגדרת כברירת מחדל לכל מטרה אחרת מלבד בדיקה.

2. יוצרים טווח כתובות 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, הכתובות משויכות לפרויקט עד שמבטלים את ההקצאה שלהן.

3. יוצרים טווח כתובות 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

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

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

5. מוסיפים את טווחי הכתובות החדשים שהוזמנו לרשת המקושרת באמצעות הפקודה הבאה, כאשר $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.

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
  }'

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]
  }'

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.

הוספת אזורים

הוספה של כמה אזורים לסביבת 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):

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