חיבור לרשת פרטית, שנוצר באמצעות Google Cloud Cross-Cloud Interconnect או Partner Interconnect, יכול להציע יתרונות משמעותיים להעברת נתונים בין AWS או Azure לבין Cloud Storage:
- אופטימיזציה פוטנציאלית של העלויות: חיסכון פוטנציאלי בעלויות של תעבורת נתונים יוצאת. האפשרות הזו יכולה להיות מועילה ללקוחות עם חיבורים קיימים בין רשתות או ללקוחות שמבצעים העברות נתונים גדולות או חוזרות, וכך לחסוך סכומים משמעותיים בטווח הארוך.
- רוחב פס ייעודי ברשת: שימוש בחיבור בין רשתות יכול לספק תפוקה עקבית וגבוהה יותר, וזמן אחזור נמוך יותר. זה חשוב במיוחד להעברות גדולות ורגישות לזמן ולסנכרון נתונים בזמן אמת.
- עמידה בדרישות התאימות: מתאים לעומסי עבודה שבהם דרישות רגולטוריות מחייבות לשמור את הנתונים מחוץ לאינטרנט הציבורי. התכונה הזו עוזרת לכם להעביר נתונים באופן פרטי באמצעות קישוריות הדדית כדי לעמוד בדרישות התאימות, לתמוך בריבונות נתונים ולפשט את הביקורות.
סקירה כללית
במאמר הזה מוסבר איך:
- הזמנה והגדרה של Cross-Cloud Interconnect
- יצירת נקודת קצה ב-S3 או ב-Azure
- הגדרה של מאזן עומסי רשת אזורי פנימי בשרת proxy עם קישוריות היברידית
- רישום מאזן העומסים ב-Service Directory
- יצירת העברה
- מוודאים שהתנועה משתמשת בחיבור בין הרשתות
ההרשאות הנדרשות
כדי להשלים כל אחד מהקטעים הבאים, תצטרכו הרשאות ספציפיות. ההרשאות האלה מפורטות בתיעוד של השלבים האלה.
אפשרויות של Interconnect
באמצעות Storage Transfer Service אפשר להעביר נתונים מ-AWS ומ-Azure דרך Cross-Cloud Interconnect (CCI) או Partner Interconnect.
השלבים הבאים ספציפיים ל-CCI, אבל הם רלוונטיים גם כשמגדירים רשתות ל-Partner Interconnect.
הזמנה והגדרה של Cross-Cloud Interconnect
Cross-Cloud Interconnect הוא חיבור פיזי ייעודי בין Google Cloud לבין ספקי ענן אחרים.
אם כבר יש לכם חיבור CCI, אתם יכולים לדלג לקטע הבא.
AWS
פועלים לפי ההוראות לקישור אל Amazon Web Services כדי להזמין ולהגדיר חיבור Cross-Cloud Interconnect חדש. כדי להגדיר את הרשת ב-Google Cloud וב-AWS, צריך את ההרשאות המתאימות.
מומלץ לצפות בסרטון שמסביר איך להזמין ולהגדיר CCI בין AWS לבין Google Cloud.
Azure
פועלים לפי ההוראות כדי להתחבר אל Microsoft Azure כדי להזמין ולהגדיר חיבור Cross-Cloud Interconnect חדש. כדי להגדיר רשתות ב-Google Cloud וב-Azure, צריך את ההרשאות המתאימות.
בסרטון הזה מוסבר איך להזמין ולהגדיר CCI בין Azure לבין Google Cloud.
אם הקטגוריה של Cloud Storage היא קטגוריה אזורית, כדאי להגדיר את CCI באותו אזור שבו נמצאת הקטגוריה כדי לצמצם את זמן האחזור ברשת.
יצירת נקודת קצה ב-S3 או ב-Azure
יוצרים נקודת קצה בחשבון S3 או Azure.
AWS
בחשבון Amazon Web Services, יוצרים נקודת קצה של VPC שמתחברת ל-S3.
כדי ליצור את נקודת הקצה, פועלים לפי ההוראות של AWS בנושא גישה לשירות AWS באמצעות נקודת קצה של ממשק VPC.
Azure
מגדירים נקודת קצה פרטית בחשבון האחסון ב-Azure לפי השלבים האלה.
Storage Transfer Service דורש את נקודת הקצה *.blob.core.microsoft.net. אין תמיכה בנקודת הקצה *.dfs.core.microsoft.net.
אחרי שיוצרים את נקודת הקצה, רושמים את כתובת ה-IP שלה. תצטרכו לציין את כתובת ה-IP כשתיצרו את מאזן העומסים בקטע הבא.
הגדרה של מאזן עומסי רשת אזורי פנימי בשרת proxy עם קישוריות היברידית
ב-Google Cloud, מגדירים מאזן עומסי רשת פנימי אזורי לשרת proxy עם קישוריות היברידית. הפעולה הזו מספקת כתובת IP פנימית שמוגבלת ללקוחות שפועלים באותה רשת VPC כמו מאזן העומסים, ומנתבת תעבורה לנקודות הקצה של S3 VPC או לנקודות הקצה הפרטיות של Azure Storage שיצרתם בקטע הקודם.
צריך ליצור את מאזן העומסים באותו פרויקט ובאותה רשת VPC שבהם נמצאת נקודת החיבור ל-VLAN שמקשרת ל-Cloud Interconnect. החיבור עצמו יכול להיות בפרויקט אחר באותו ארגון, אבל ה-VPC והאזור של ה-attachment צריכים להיות זהים לאלה של מאזן העומסים.
מציינים את כתובת ה-IP של נקודת הקצה של S3 VPC או של נקודת הקצה הפרטית של Azure Storage כשמגיעים לשלבים שמסומנים בתווית Add endpoints to the hybrid connectivity NEG.
חשוב לשים לב לכתובת ה-IP ולפורט של הקצה הקדמי של ה-NLB, כי תצטרכו לציין אותם בקטע הבא.
אימות החיבור
לפני שממשיכים, מומלץ לוודא שמאזן העומסים יכול להתחבר לנקודת הקצה של האחסון המרוחק.
כדי לעשות את זה:
- יוצרים מכונה וירטואלית ב-Compute Engine באותה רשת VPC שבה נמצא מאזן העומסים.
מהמכונה הווירטואלית, משתמשים ב-
curlכדי לבדוק את הקישוריות לכתובת ה-IP ולפורט של מאזן העומסים:curl -v --resolve HOSTNAME:PORT:LOAD_BALANCER_IP https://HOSTNAMEמחליפים את מה שכתוב בשדות הבאים:
- HOSTNAME הוא שם המארח של ספק שירותי האחסון של המקור.
- ב-AWS S3, משתמשים בנקודת קצה ל-API של S3 לאזור של הדלי, לדוגמה
s3.us-west-1.amazonaws.com. - ב-Azure Storage, משתמשים בנקודת הקצה של ה-blob בחשבון האחסון, לדוגמה
mystorageaccount.blob.core.windows.net.
- ב-AWS S3, משתמשים בנקודת קצה ל-API של S3 לאזור של הדלי, לדוגמה
- PORT היא היציאה שהגדרתם בכלל ההעברה של מאזן העומסים, בדרך כלל
443. - LOAD_BALANCER_IP היא כתובת ה-IP של הקצה הקדמי של מאזן העומסים.
- HOSTNAME הוא שם המארח של ספק שירותי האחסון של המקור.
תשובה מנקודת הקצה המרוחקת, גם אם היא שגיאה, מציינת שהקישוריות תקינה. פסק זמן לחיבור מצביע על הגדרה שגויה בהגדרת הרשת, שצריך לפתור לפני שממשיכים.
רישום של NLB ב-Service Directory
רושמים את ה-NLB בספריית השירותים. Storage Transfer Service משתמש ב-Service Directory כדי לפתור את הכתובת של מאזן העומסים ולהתחבר אליו ישירות.
פועלים לפי ההוראות כדי לרשום מאזן עומסים פנימי. משתמשים בכתובת ה-IP ובפורט של מאזן העומסים שיצרתם כשמציינים את כלל ההעברה.
אחרי שיוצרים את השירות, רושמים את הקישור העצמי שלו. הפורמט הוא projects/{project_id}/locations/{location}/namespaces/{namespace}/services/{service}.
תצטרכו את הערך הזה כשתיצרו את משימת ההעברה.
יצירת העברה
נותנים לסוכן השירות את ההרשאות הבאות. הוראות לאחזור סוכן השירות ולהענקת הרשאות לסוכן השירות מופיעות במאמר הרשאות של סוכן שירות שמנוהל על ידי Google.
- התפקיד 'צפייה בספריית השירותים' (roles/servicedirectory.viewer) ברמת הפרויקט, בפרויקט שמכיל את המשאבים של ספריית השירותים.
- ההרשאה Private Service Connect Authorized Service (roles/servicedirectory.pscAuthorizedService) ברמת הפרויקט, בפרויקט שמכיל את ה-VPC.
- Storage Legacy Bucket Writer (roles/storage.legacyBucketWriter) בקטגוריית היעד.
כדי ליצור העברת נתונים באמצעות Cross-Cloud Interconnect, צריך להשתמש ב-API בארכיטקטורת REST של Storage Transfer Service. שולחים בקשה באופן הבא.
שימו לב לשדה privateNetworkService, שבו תציינו את ה-selfLink של שירות Service Directory.
AWS
POST https://storagetransfer.googleapis.com/v1/transferJobs
{
"status": "ENABLED",
"projectId": "PROJECT_ID",
"transferSpec": {
"awsS3DataSource": {
"privateNetworkService": "SERVICE_SELF_LINK",
"bucketName": "S3_BUCKET_NAME",
"awsAccessKey": {
"accessKeyId": "ACCESS_KEY_ID",
"secretAccessKey": "SECRET_ACCESS_KEY"
}
},
"gcsDataSink": {
"bucketName": "GCS_BUCKET_NAME"
}
}
}
Azure
POST https://storagetransfer.googleapis.com/v1/transferJobs
{
"status": "ENABLED",
"projectId": "PROJECT_ID",
"transferSpec": {
"azureBlobStorageDataSource": {
"privateNetworkService": "SERVICE_SELF_LINK",
"storageAccount": "AZURE_SOURCE_NAME",
"container": "AZURE_CONTAINER",
"azureCredentials": {
"sasToken": "AZURE_SAS_TOKEN",
}
},
"gcsDataSink": {
"bucketName": "GCS_BUCKET_NAME"
}
}
}
מחליפים את מה שכתוב בשדות הבאים:
- SERVICE_SELF_LINK הוא הקישור העצמי של שירות Service Directory. הפורמט הוא
projects/{project_id}/locations/{location}/namespaces/{namespace}/services/{service}.
מידע על שדות אחרים מופיע במסמכי העיון בנושא transferSpec.
מוודאים שהתנועה משתמשת בחיבור בין הרשתות
משתמשים ב-Cloud Monitoring כדי לוודא שהתעבורה עוברת דרך הקישוריות ההדדית מ-AWS או מ-Azure.
- במסוף Google Cloud, עוברים אל Hybrid Connectivity > Cloud Interconnect.
- בוחרים את צירוף ה-VLAN שמתחבר לסביבת AWS או Azure.
- בדף הפרטים של החיבור, בוחרים בכרטיסייה מעקב. חפשו מדדים שמצביעים על העברת נתונים. באופן ספציפי:
- Ingress Bytes: המדד הזה מציג את הנתונים שמגיעים מ-AWS או מ-Azure אל ה-VPC שלכם ב-Google Cloud.
- סטטוס הפעולה: מוודאים שהחיבור הפיזי וסשן ה-BGP נמצאים במצב תקין ופעיל.