המסמך הזה עוזר לארכיטקטים של ענן ולמומחי תפעול להחליט איך להתחבר Google Cloud לספקים אחרים של שירותי ענן (CSP) כמו Amazon Web Services (AWS) ו-Microsoft Azure. בתכנון של סביבת מולטי-ענן, חיבורים בין ספקי CSP מאפשרים העברת נתונים בין הרשתות הווירטואליות שלכם. המסמך הזה מספק גם מידע על אופן ההטמעה של האפשרות שתבחרו.
ארגונים רבים פועלים בכמה פלטפורמות ענן, או כאמצעי זמני במהלך העברה או כי לארגון יש אסטרטגיה ארוכת טווח לשימוש בכמה עננים.
יש כמה אפשרויות להחלפת נתונים בין Google Cloud לבין ספקי CSP אחרים, והן מפורטות במסמך הזה:
- העברת נתונים דרך כתובות IP ציבוריות באינטרנט.
- שימוש בשירות VPN מנוהל בין Google Cloud לבין ספק שירותי הענן האחר.
- שימוש ב-Partner Interconnect ב- Google Cloud כדי להתחבר לשותף שיכול להתחבר ישירות לספק שירותי הענן השני.
- שימוש ב-Dedicated Interconnect ב- Google Cloud כדי להעביר נתונים לספק שירותי הענן השני דרך נקודת נוכחות (PoP) משותפת.
- שימוש ב-Cross-Cloud Interconnect ב- Google Cloud לחיבור מנוהל לספק CSP אחר.
האפשרויות האלה שונות מבחינת מהירות ההעברה, זמן האחזור, המהימנות, הסכמי רמת השירות (SLA), המורכבות והעלויות. במסמך הזה מתוארת כל אפשרות בפירוט, כולל היתרונות והחסרונות שלה, ובסופו יש השוואה בין כל האפשרויות.
במסמך הזה מוסבר על העברת נתונים בין מכונות וירטואליות שנמצאות ב-Google Cloud לבין רשתות וירטואליות של ספקי CSP אחרים. לגבי נתונים שמאוחסנים בGoogle Cloud מוצרים אחרים כמו Cloud Storage וBigQuery, אפשר לעיין בקטע שמתייחס למוצרים האלה.
המסמך הזה יכול לשמש כהנחיה להערכת האפשרויות להעברת נתונים בין Google Cloud לבין ספקי CSP אחרים, בהתאם לדרישות וליכולות שלכם.
הקונספטים במסמך הזה רלוונטיים למספר מקרים:
- כשמתכננים להעביר כמויות גדולות של נתונים לפרק זמן קצר, למשל, במסגרת פרויקט להעברת נתונים.
- אם אתם מפעילים העברות נתונים רציפות בין כמה ספקי שירותי ענן, למשל כי עומסי העבודה של המחשוב פועלים אצל ספק אחר של שירותי ענן, ועומסי העבודה של הביג דאטה משתמשים ב- Google Cloud.
שיקולים ראשוניים
לפני שבוחרים איך לחבר את סביבות הענן, חשוב לבדוק אילו אזורים בוחרים בכל סביבה, ולוודא שיש אסטרטגיה להעברת נתונים שלא נמצאים בסביבות של רשתות וירטואליות.
בחירת אזורים בענן
אם המשאבים של Google Cloud וספקי CSP אחרים נמצאים באזורים שקרובים זה לזה מבחינה גיאוגרפית, יש יתרון בעלויות ובזמן האחזור בהעברת נתונים בין ספקי ענן.
בתרשים הבא מוצגת זרימת הנתונים בין Google Cloud
לבין ספקי CSP אחרים.
בכל שיטת העברה, הנתונים זורמים מ- Google Cloud אל ספק שירותי הענן השני באופן הבא:
- מהאזור Google Cloud שבו מתארחים המשאבים ועד לנקודת הנוכחות (PoP) של Google.
- דרך מתקן של צד שלישי בין Google Cloud לבין ספק ה-CSP השני.
- מנקודת הקצה PoP של ספק ה-CSP השני לאזור שבו נמצאים המשאבים בתוך הרשת של ספק ה-CSP השני.
נתונים שזורמים מספק ה-CSP השני Google Cloud עוברים באותו נתיב, אבל בכיוון ההפוך.
הנתיב מקצה לקצה קובע את זמן האחזור של העברת הנתונים. בפתרונות מסוימים, עלויות הרשת עולות גם אם נקודות ה-PoP של שני הספקים לא נמצאות באותו אזור מטרופוליטני. פרטים מופיעים בקטע התמחור של כל פתרון.
חשוב לבחור בכל ענן אזורים מתאימים שיכולים לארח את עומסי העבודה המיועדים. אפשר לעיין בדף מיקומים של Google Cloud ובדפים דומים של ספקי CSP אחרים, כמו טבלת האזורים של AWS או מוצרי Azure לפי אזור. לקבלת עזרה כללית בבחירת מיקום אחד או יותר ב- Google Cloud, אפשר לעיין במאמר שיטות מומלצות לבחירת אזורים ב-Compute Engine.
העברת נתונים ב-Cloud Storage וב-BigQuery
כברירת מחדל, רק נתונים שנמצאים בסביבת Google Cloud VPC עוברים דרך מנהרת Cloud VPN או דרך חיבור Cloud Interconnect.
אם רוצים להעביר נתונים אל שירותי Google אחרים וממנו, אפשר להשתמש ב-Private Service Connect וב-גישה פרטית ל-Google למארחים מקומיים מהסביבה של ספק שירותי הענן האחר.
אם רוצים להעביר אחסון אובייקטים, מסד נתונים, מחסן נתונים או מוצרים אחרים של ספק CSP אחר, צריך לעיין במסמכים שלו כדי לראות אם אפשר להעביר נתונים דרך מוצר הקישוריות או ה-VPN המנוהל שלו. אפשרות אחרת היא להעביר את הנתונים האלה דרך מכונות וירטואליות של פרוקסי שהגדרתם בסביבה של ספק שירותי הענן הרלוונטי, כדי שהם יעברו דרך החיבור הרצוי.
כדי להעביר נתונים ל-Cloud Storage או ל-BigQuery, אפשר גם להשתמש בשירות העברת הנתונים או בשירות העברת הנתונים ל-BigQuery.
העברה דרך כתובות IP חיצוניות באינטרנט
הדרך הקלה ביותר להעביר נתונים בין Google Cloud לבין ספק CSP אחר היא להשתמש באינטרנט ולהעביר את הנתונים באמצעות כתובות IP חיצוניות.
הדיאגרמה הבאה ממחישה את הרכיבים של הפתרון הזה.
בין קצה הרשת של Google לבין קצה הרשת של ספק שירותי הענן האחר, הנתונים עוברים דרך האינטרנט או דרך קישור ישיר בין רשתות שכנות (direct peering) בין Google Cloud לבין ספק שירותי הענן האחר. הנתונים יכולים לעבור רק בין משאבים שהוקצו להם כתובות IP ציבוריות.
איך Google מתחברת לרשתות אחרות
נקודות הקצה PoP של Google הן המקומות שבהם הרשת של Google מתחברת לרשתות אחרות שביחד יוצרות את האינטרנט. Google נמצאת במיקומים רבים ברחבי העולם.
באינטרנט, לכל רשת מוקצה מספר מערכת אוטונומית (ASN) שכולל את תשתית הרשת הפנימית של הרשת ואת הנתיבים שלה. מספר ה-ASN העיקרי של Google הוא 15169.
יש שתי דרכים עיקריות שבהן רשת יכולה לשלוח תנועה אל Google או לקבל תנועה מ-Google:
- רכישת שירותי אינטרנט מספק אינטרנט שכבר יש לו קישוריות ל-Google (AS15169). האפשרות הזו נקראת בדרך כלל IP transit והיא דומה למה שצרכנים ועסקים רוכשים מספקי גישה לבתים ולעסקים שלהם.
- להתחבר ישירות ל-Google (AS15169). האפשרות הזו נקראת peering, והיא מאפשרת לרשת לשלוח ולקבל תעבורה ישירות אל Google (AS15169) בלי להשתמש ברשת של צד שלישי. בדרך כלל, עדיף להשתמש בפירינג במקום בטרנזיט, כי מפעילים של רשתות מקבלים יותר שליטה על האופן שבו התנועה מועברת ועל המיקום שלה, וכך אפשר לבצע אופטימיזציה של הביצועים והעלויות. פירינג הוא מערכת וולונטרית. כשבוחרים לבצע פירינג, מפעילי רשת מחליטים יחד באילו מתקנים להתחבר, כמה רוחב פס להקצות, איך לחלק את עלויות התשתית וכל פרט אחר שנדרש להגדרת החיבורים. ל-AS15169 יש מדיניות פתוחה בנושא שיתוף פעולה בין רשתות, כלומר אם רשת עומדת בדרישות הטכניות, Google תשתף איתה פעולה.
קישור בין רשתות (peering) הוא הסכם פרטי ומועיל הדדית בין שתי רשתות עצמאיות. לכן, בדרך כלל רשתות לא חושפות לציבור עם מי הן מקושרות במיקומים מסוימים, כמה רוחב פס זמין וכו'. אבל בגלל היקף הפעילות ומדיניות פתוחה, Google מקושרת ישירות כמעט לכל ספקי האינטרנט הגדולים ולספקי שירותי הענן במספר מיקומים ובאזורים שונים. צוות הרשת של Google עובד ישירות עם הצוותים המקבילים ברשתות האלה כדי לספק קישוריות מספקת שתענה על הביקוש.
מידע נוסף על אופן הפעולה של שיתוף פעולה בין רשתות באינטרנט זמין במאמר The Internet Peering Playbook.
הטמעה
במקרה כזה, לכל המכונות הווירטואליות שמעבירות נתונים ביןGoogle Cloud לבין ספקי שירותי ענן אחרים צריך להיות כתובת IP ציבורית. בצד אחד, צריך לפתוח את חומת האש כדי לאפשר חיבור מכתובת ה-IP הציבורית של ספק שירותי הענן השני. לא נדרשים שלבים נוספים כי חילופי הנתונים מתבצעים דרך חיבור האינטרנט הקיים.
מהירות העברה וזמן אחזור
למרות שאין מהירות וחביון מובטחים בנתיב דרך האינטרנט, בדרך כלל, ספקי CSP גדולים ו-Google מחליפים נתונים ישירות בכמה מיקומים ברחבי העולם. הקיבולת משותפת עם לקוחות ושירותים אחרים, אבל בדרך כלל, בגלל החיבור הישיר בין שני הספקים, זמן האחזור דומה או נמוך יותר מאשר באפשרויות אחרות.
מומלץ לבדוק את זמן האחזור ואת רוחב הפס בין Google Cloud לבין ספקי ה-CSP האחרים באזורים שבחרתם. אפשר לבצע השוואה מהירה באמצעות כלים כמו iperf או netperf, או להריץ השוואה מותאמת אישית ומקיפה יותר על סמך האפליקציה שלכם. התנאים עשויים להשתנות לאורך זמן, אבל ההשוואה יכולה לספק אינדיקציה לגבי הביצועים שאתם יכולים לצפות להם, ולעזור לכם להבין אם הפתרון הזה עונה על הצרכים שלכם. אם אתם צריכים רוחב פס ייעודי בין שתי הסביבות, כדאי לבחור פתרון אחר.
שימו לב שלמוצרים מספקים שונים יכולים להיות מאפייני ביצועים שלא תמיד תואמים. לדוגמה, הקיבולת של VPN מסוג IPsec לכל מנהרה עשויה להשתנות מספק לספק.
אבטחה
התעבורה באינטרנט לא מוצפנת, ויכול להיות שהיא תעבור דרך ספקי אינטרנט (ISP), מערכות אוטונומיות ומתקנים של צדדים שלישיים. לכן, צריך להצפין תנועה רגישה בשכבת האפליקציה או לבחור פתרון אחר.
אמינות והסכם רמת שירות (SLA)
Google Cloud בדרך כלל יש כמה נתיבים מגוונים לקישוריות לאינטרנט מאזורים, ויש חיבורי קישור ישיר בין רשתות שכנות (direct peering) עם ספקי CSP גדולים אחרים בכמה מיקומים ברחבי העולם.
עם זאת, Google Cloud לא מספק הסכמי רמת שירות (SLA) לגבי קישוריות לספקי CSP אחרים דרך האינטרנט. כדאי לבדוק את הסכמי ה-SLA של ספקי CSP אחרים, אבל בדרך כלל הם מתייחסים רק לקישוריות לאינטרנט באופן כללי ולא לספקים ספציפיים.
יכול להיות שלספקים שונים יש מדיניות שונה לגבי ניתוב שיחות, מה שיכול להשפיע על הזמינות. לדוגמה, בדף peeringdb, אמזון מסבירה שהרבה אזורים ב-AWS מכריזים רק על מסלולים מקומיים, כי עננים וירטואליים פרטיים (VPC) ב-AWS הם אזוריים בלבד (עננים וירטואליים פרטיים ב-Google Cloud הם גלובליים). המשמעות היא שהלקוחות עשויים להסתמך על קישורים במיקום אחד של שותפות אינטרנט, כי התנועה שיוצאת מ- Google Cloud יכולה להשתמש רק בקישורים האלה כדי להגיע ליעד. זה בסדר בפעולה רגילה עם תנועה שמועברת בתוך האזור, אבל מומלץ ללקוחות לתכנן פריסות במספר אזורים כדי להתמודד עם כשלים אזוריים. יכול להיות שיהיה צורך להגדיר שערים ומנהרות נוספים, קישור בין רשתות וירטואליות או טופולוגיות אחרות של כמה אזורים בענן של צד שלישי.
בנוסף, צריך לבנות את האפליקציות כך שהן יפעלו גם אם יש בעיות בחיבור, כמו שמומלץ בספר ה-SRE של Google SRE. לדוגמה, אם אתם בונים אפליקציה שמסתמכת על היכולת להגיע לשירות של צד שלישי באמצעות ניתוב באינטרנט, ודאו שהאפליקציה עדיין פועלת, או לפחות מחזירה למשתמש הודעות שגיאה מועילות במקרה של בעיות בקישוריות.
כשמתרחשות בעיות בניתוב באינטרנט, צוות הרשת של Google מנסה לשחזר את הקישוריות עם הצד השלישי. עם זאת, לא כל הבעיות בשליטת Google. לכן, במקרים מסוימים, התיקון עשוי להיות תלוי בפעולת שחזור של צד שלישי (ספק אינטרנט או ספק ענן). ללקוחות יש את ההשפעה הגדולה ביותר על האופן שבו המפעילים מגיבים להפסקות שירות, לכן חשוב לוודא שיש לכם כיסוי תמיכה אצל כל הספקים ותוכנית להעברת בעיות לטיפול ברמה גבוהה יותר אם משהו משתבש. בנוסף, מומלץ לבצע תרגילי BCP (תהליך המשכיות עסקית) תקופתיים כדי לוודא את העמידות של אפליקציות שארכיטקטורת הענן שלהן מבוססת על כמה ספקי ענן.
תמחור
על העברת נתונים באינטרנט חלים תעריפי יציאה רגילים מהאינטרנט עבור תעבורת נתונים שיוצאת מ- Google Cloud. במקרים שבהם זמן האחזור לא קריטי, שימוש במסלול שירות הרשת הרגיל מספק תמחור נמוך יותר.
לספקי CSP אחרים יש חיובים משלהם על העברת נתונים. במקרים רבים, הם מחייבים רק על תעבורה שיוצאת מהרשת שלהם. כדאי לעיין במחירון של ספק ה-CSP שלכם. לדוגמה, ב-AWS אפשר לעיין בחיובים על העברת נתונים ב-EC2 וב-Azure אפשר לעיין בפרטים על תמחור רוחב פס.
VPN מנוהל בין ספקי ענן
אתם יכולים להשתמש בשירותי VPN מנוהלים משני ספקי הענן, ויש לכך שני יתרונות: השירות מספק ערוץ מוצפן בין רשתות וירטואליות בשני סביבות הענן, והוא מאפשר להעביר נתונים באמצעות כתובות IP פרטיות. זהו פתרון מתקדם יותר להעברת נתונים באינטרנט, שלא דורש חומרה או שותפים.
הדיאגרמה הבאה ממחישה את הרכיבים של הפתרון הזה.
בפתרון הזה, הנתונים מוצפנים ב- Google Cloud באמצעות Cloud VPN ופתרון VPN עבור ספק שירותי הענן השני. העברת הנתונים בין Google Cloud לבין ספק שירותי הענן השני מתבצעת באינטרנט, כמו בפתרון הקודם. Google Cloud
הטמעה
Google מציעה את HA VPN כשירות VPN מנוהל למנהרות IPsec מוצפנות, שאפשר להשתמש בהן בצד של Google. ספקי CSP אחרים מציעים מוצרי VPN מנוהלים משלהם, שבהם אפשר להשתמש כדי ליצור מנהרות IPsec VPN בין שני הסביבות. לדוגמה, AWS מציעה את AWS Site-to-Site VPN ו-Azure מציעה את Azure VPN gateway. אפשר לחבר את הרשתות הווירטואליות בין הסביבות באמצעות מנהרות VPN.
אפשר להתחבר לספק אחר של שירותי ענן באמצעות HA VPN בלבד, או להגדיר HA VPN כרכזת היברידית של Network Connectivity Center. בעזרת Network Connectivity Center אפשר לחבר מיקומים מקומיים, רשתות VPC ועננים אחרים באמצעות ניהול מרכזי.
ל-HA VPN אין פונקציונליות מובנית של תרגום כתובות רשת (NAT). עם זאת, אפשר להפעיל Hybrid NAT בחיבור.
עם Cloud Router במצב ניתוב דינמי גלובלי, אפשר להגיע לכל האזורים ברשת VPC גלובלית באמצעות מנהרות VPN לאותו אזור בלבד. אצל ספקי CSP אחרים, יכול להיות שתצטרכו מנהרות VPN לכל אזור. אם יש לכם כמה רשתות וירטואליות בסביבת ענן שלא מקושרות, תצטרכו לחבר את כל הרשתות הווירטואליות שצריכות לתקשר ביניהן באופן עצמאי באמצעות VPN.
Google Cloud מציעה מדריכים להפעלה הדדית, עם הוראות מפורטות להגדרת מנהרות VPN לספקי ענן גדולים אחרים:
מהירות העברה וזמן אחזור
כשמשתמשים במנהרות VPN מנוהלות, הנתונים עוברים בערך באותם נתיבי אינטרנט כמו במצב שבו לא משתמשים במנהרות VPN. זמן האחזור שמתקבל צריך להיות דומה לזמן האחזור באפשרות הקודמת, עם תקורה קטנה של זמן אחזור עבור מנהרות ה-VPN. רוחב הפס הזמין מוגבל על ידי רוחב הפס המקסימלי לכל מנהרת VPN ב- Google Cloud, רוחב הפס המקסימלי של המנהרות של ספק הענן האחר ורוחב הפס הזמין בנתיב האינטרנט.
כדי להגדיל את רוחב הפס, אפשר לפרוס מנהרות נוספים. מידע נוסף על פריסת פתרון כזה זמין במאמר טופולוגיות של HA VPN להגדלת רוחב הפס.
אפשר לבדוק את זמן האחזור ואת רוחב הפס כמו שמתואר בקטע האחרון, אבל התנאים עשויים להשתנות עם הזמן, ואין ערובה לזמן האחזור או לרוחב הפס.
אבטחה
התנועה במנהרות IPsec VPN מוצפנת באמצעות צפנים שמקובלים על שני ספקי הענן. מידע נוסף זמין במאמרים צפני IKE שנתמכים ב-Cloud VPN, שאלות נפוצות בנושא AWS VPN ופרמטרים של IPsec/IKE ב-Azure VPN.
אמינות והסכם רמת שירות (SLA)
Cloud VPN מציע SLA. ספקי CSP אחרים מציעים לפעמים הסכמי SLA על מוצר ה-VPN המנוהל שלהם, לדוגמה, AWS Site-to-Site VPN SLA ו-Azure SLA for VPN Gateway. עם זאת, הסכמי ה-SLA האלה מכסים רק את הזמינות של שער ה-VPN ולא כוללים קישוריות לספקי CSP אחרים דרך האינטרנט, ולכן אין SLA על הפתרון מקצה לקצה.
כדי לשפר את המהימנות, מומלץ להשתמש במעברי VPN נוספים ובמנהרות VPN גם ב- Google Cloud וגם בספקי CSP אחרים.
תמחור
שירות ה-VPN המנוהל כרוך בתשלום. במקרה של Google Cloud, חל תשלום שעתי. פרטים נוספים זמינים במחירון של Cloud VPN. לספקי CSP אחרים, אפשר לעיין במחירונים שלהם. לדוגמה, מחירון החיבור של AWS Site-to-Site VPN או מחירון של Azure VPN Gateway.
בנוסף לתמחור לפי שעה של שירות ה-VPN, צריך לשלם על נתונים שמועברים דרך שער ה-VPN. ב- Google Cloud ובספקי CSP רבים אחרים, חלים חיובים רגילים על העברת נתונים באינטרנט, כפי שמפורט במאמר העברה דרך כתובות IP חיצוניות באינטרנט. במקרים רבים, החיובים על העברת נתונים גבוהים מהעלות הקבועה של הפתרון הזה.
Partner Interconnect עם שותפים שמופעל בהם multicloud
Partner Interconnect מאפשר לכם לחבר ענן וירטואלי פרטי לרשתות וירטואליות של ספקי ענן אחרים דרך הרשת של שותפים נבחרים שמציעים פתרונות ישירים לריבוי עננים. כדי להתחבר, אתם צריכים לפרוס מופע וירטואלי אחד או יותר של ניתוב, שמטפל בהגדרה הנדרשת של Border Gateway Protocol (BGP).
בתרשים הבא מוצג setup מיותר שמשתמש בשני חיבורים של Partner Interconnect.
המסלולים מועברים בין Cloud Router לבין השער בצד של ספק הענן השני דרך מופע ניתוב וירטואלי שמנוהל על ידי השותף שמספק את הקישוריות. התנועה זורמת דרך רשת השותף ביןGoogle Cloud לבין ספק הענן השני.
הטמעה
כדי להשתמש בפתרון הזה, צריך להגדיר כמה רכיבים:
- בצד Google Cloud , מגדירים את Partner Interconnect עם ספק שירותי קישוריות שמשרת את האזורים Google Cloud ומציע קישוריות מרובת עננים לספק שירותי הענן האחר.
- בספק ה-CSP השני, צריך להשתמש במוצר הקישוריות שלו כדי להתחבר לאותו שותף. לדוגמה, ב-AWS אפשר להשתמש ב-Direct Connect וב-Azure אפשר להשתמש ב-ExpressRoute.
- בצד של ספק השירות השותף, צריך להגדיר את ציוד הניתוב הווירטואלי שמספק את סשני ה-BGP אל Google Cloud ואל ספק שירותי הענן השני.
אפשר להתחבר באמצעות Partner Interconnect בלבד, או להגדיר את Partner Interconnect כ-Network Connectivity Center – רכזת היברידית. Network Connectivity Center מאפשר לכם לחבר מיקומים מקומיים, רשתות VPC ועננים אחרים באמצעות ניהול מרכזי.
אם יש חפיפה בין מרחבי כתובות ה-IP בשני סביבות ה-CSP, אפשר להפעיל Hybrid NAT בחיבור.
מהירות העברה וזמן אחזור
הפתרון הזה מציע קיבולת ייעודית בין Google Cloud לבין ספקי CSP אחרים. הקיבולת הזמינה לצירוף קבצים עשויה להשתנות בהתאם לשותף ולספק שירותי הענן האחר. בצד של Google Cloud , Partner Interconnect זמין עם קיבולת של קובץ מצורף בין 50 Mbps ל-50 Gbps.
ההשהיה של הפתרון הזה היא סכום הערכים הבאים:
- זמן האחזור בין האזור שבו המשאבים שלכם מתארחים ב-Google Cloud לבין מיקום ה-Interconnect שבו השותף מתחבר ל- Google Cloud.
- השהיה ברשת השותפים אל, מ, ובאמצעות מופע הניתוב הווירטואלי אל ספק ה-CSP השני.
- זמן האחזור ממיקום הקצה של ספק הענן השני שבו מתבצעת הקישוריות עם השותף, לאזור שבו מתארחים המשאבים בספק הענן.
כדי להשיג את זמן האחזור הנמוך ביותר האפשרי, מיקומי הקצה של Google Cloud וספק שירותי הענן האחר צריכים להיות באותו אזור מטרופוליני, יחד עם מופע הניתוב הווירטואלי. לדוגמה, יכול להיות שיהיה לכם חיבור עם זמן אחזור נמוך אם האזורים בענן של שני ספקי שירותי הענן, כמו גם נקודת ה-PoP בקצה ומופע הניתוב הווירטואלי, ממוקמים באזור אשבורן שבווירג'יניה.
למרות ש- Google Cloud וספקי CSP רבים אחרים לא מציעים ערבויות לגבי זמן האחזור של התנועה לקצה הרשת שלהם, בדרך כלל זמן האחזור בפתרון הזה פחות משתנה מאשר אם משתמשים בכתובות IP חיצוניות או בפתרון VPN, כי יש נתיב ייעודי וקיבולת דרך השותף.
אבטחה
התעבורה דרך Partner Interconnect לא מוצפנת כברירת מחדל. כדי לאבטח את התעבורה, אפשר לפרוס HA VPN over Cloud Interconnect בצד Google Cloud של החיבור. ספקי CSP אחרים מאפשרים להשתמש בשירות ה-VPN המנוהל שלהם דרך חיבור רשת; לדוגמה, אפשר להשתמש ב-AWS Site-to-Site VPN דרך AWS Direct Interconnect. לחלופין, אפשר גם להשתמש במכשיר וירטואלי שמצפין את התנועה בצד של ספק ה-CSP השני.
אפשרות נוספת היא להצפין את התנועה בשכבת האפליקציה במקום להשתמש ב-VPN.
אמינות והסכם רמת שירות (SLA)
הפתרון הזה כולל שלושה הסכמי רמת שירות שונים: אחד מ-Google, אחד משותף הקישוריות ואחד מספק שירותי הענן האחר.
כשמשתמשים ב-Partner Interconnect באופן יתיר, Google מציעה הסכמי רמת שירות (SLA) חודשיים של 99.9% עד 99.99%, בהתאם לסוג הטופולוגיה שנבחרה. אין הסכם רמת שירות על חיבור יחיד של Partner Interconnect.
כדי לראות את ה-SLA של מוצר ה-Interconnect של ספק CSP אחר, אפשר לעיין במסמכי התיעוד שלו, למשל SLA של AWS Direct Connect או SLA של ExpressRoute ב-Azure.
כדי לראות את הסכם רמת השירות (SLA) של Partner Interconnect בנוגע לזמינות של הקישוריות ושל מופע הניתוב הווירטואלי, אפשר לעיין במסמכים או בתנאים של ספק השירות השותף. לדוגמה, אפשר לעיין בהסכם השירותים הגלובלי של Megaport.
תמחור
בצד Google Cloud יש עמלה חודשית לכל חיבור Partner Interconnect, בהתאם לרוחב הפס. התנועה שיוצאת דרך Partner Interconnect מחויבת בשיעור נמוך יותר מהתנועה באינטרנט. מידע נוסף מופיע בדף התמחור של Partner Interconnect.
כדי לראות את התמחור של מוצר הקישוריות של ספק CSP אחר, אפשר לעיין בדף התמחור שלו, למשל התמחור של AWS Direct Connect או התמחור של Azure ExpressRoute. בדרך כלל, התמחור כולל גם חיוב חודשי על הקישוריות וחיובים על העברת נתונים דרך הקישוריות, בשיעור נמוך יותר מאשר באינטרנט.
השותף מספק שירותי קישוריות בין רשתות ומחייב עליהם לפי התמחור שלו, שמופיע באתר שלו או שאפשר לקבל אותו מצוות המכירות שלו. בדרך כלל, אם כל העברות הנתונים מתבצעות באותו אזור מטרופוליטני, העלויות נמוכות בהרבה מאשר אם הנתונים צריכים לעבור מרחק גדול יותר ברשת של השותף.
כשמעבירים נתונים באופן קבוע בכמויות גדולות מספיק, הפתרון הזה יכול לפעמים להציע את העלות הכוללת הכי נמוכה, בהתאם למחירים של ספק ה-CSP האחר, בגלל שיעורי תעבורת נתונים יוצאת (egress) המוזלים. גם כשמוסיפים את העלויות החודשיות של הקישוריות ל-Partner Interconnect, של ספק ה-CSP האחר ושל ספק השירות השותף, השימוש בפתרון הזה יכול לספק חיסכון משמעותי. מכיוון שהמחירים של השותפים ושל ספקי ה-CSP האחרים יכולים להשתנות ללא הודעה מוקדמת, מומלץ לבצע השוואה משלכם באמצעות הצעות מחיר עדכניות מכל הגורמים המעורבים.
חיבור Dedicated Interconnect דרך נקודת נוכחות (PoP) משותפת
באמצעות מכשירי ניתוב פיזיים במתקן קישוריות משותף בין Google Cloud לבין ספק שירותי הענן האחר, אפשר לחבר את שני ספקי שירותי הענן באמצעות Dedicated Interconnect בצד שלGoogle Cloud ומוצר מקביל בספק שירותי הענן האחר. המיקום של הקישוריות לא בהכרח זהה למיקום של האזור שבו נמצאים המשאבים.
התרשים הבא מציג הגדרה עם יתירות באמצעות שני חיבורי Dedicated Interconnect:
המסלולים מועברים בין Cloud Router לבין השער בצד של ספק שירותי הענן השני דרך נתב פיזי שמוצב במתקן משותף לחיבור בין רשתות. התנועה עוברת דרך הנתב הזה בין Google Cloud לבין ספק שירותי הענן השני.
הטמעה
הפתרון הזה מחייב אירוח ותחזוקה של מכשירי ניתוב פיזיים במתקן לאחסון ואירוח שרתים (colocation facility) שבו נמצאים Google וספק שירותי הענן שאליו רוצים להתחבר. ממכשיר הניתוב הזה, מזמינים שני חיבורים פיזיים עם המתקן: אחד לכיוון Google Cloud באמצעות Dedicated Interconnect, ואחד לכיוון ספק השירות השני באמצעות מוצר מקביל, למשל, AWS Direct Connect או Azure ExpressRoute. במכשיר הניתוב, צריך להגדיר BGP כדי לאפשר החלפת מסלולים בין שתי סביבות הענן.
כדי לזהות מיקומים מתאימים להגדרה הזו, כדאי לעיין ברשימת המיקומים של מתקני לאחסון ואירוח שרתים (colocation facility) מ- Google Cloud ובמיקומים של ספקי CSP אחרים, למשל AWS Direct Connect Locations או Azure ExpressRoute peering locations.
אתם יכולים להתחבר באמצעות Dedicated Interconnect בלבד, או להגדיר את Dedicated Interconnect כ-Network Connectivity Center מסוג hub-and-spoke היברידי. המרכז לקישוריות רשתות מאפשר לכם לחבר מיקומים מקומיים, רשתות VPC ועננים אחרים באמצעות ניהול מרכזי.
אם יש חפיפה בין מרחבי כתובות ה-IP בשני סביבות ה-CSP, אפשר להפעיל Hybrid NAT בחיבור.
הפתרון הזה יעיל אם אתם משתמשים בקישוריות הייעודית גם כדי להתחבר בחזרה לסביבה המקומית שלכם, בנוסף לחיבור לספק CSP אחר.
במקרים אחרים, הפתרון הזה מורכב כי הוא מחייב בעלות על ציוד פיזי ותחזוקה שלו, וגם חוזה עם מתקן לאחסון ואירוח שרתים (colocation facility). אנחנו ממליצים על הפתרון הזה רק אם לפחות אחד מהתנאים הבאים מתקיים:
- כבר יש לכם ציוד במתקן מתאים למטרה אחרת וחוזה קיים עם המתקן.
- אתם מעבירים כמויות גדולות של נתונים באופן קבוע, ולכן זו אפשרות חסכונית, או שיש לכם דרישות רוחב פס שהשותפים לא יכולים לספק.
מהירות העברה וזמן אחזור
הפתרון הזה מציע קיבולת ייעודית בין Google Cloud לבין ספק CSP אחר. בצד Google Cloud , אפשר להשתמש ב-Dedicated Interconnect באמצעות חיבור פיזי אחד או יותר של 10 או 100 Gbps.
ההשהיה של הפתרון הזה היא סכום הערכים הבאים:
- השהייה בין האזור שבו המשאבים שלכם מתארחים ב-Google Cloud לבין מיקום הקישוריות שבו אתם מתחברים ל-Google Cloud.
- השהיה דרך המתקן והציוד הפיזי שלכם, שבדרך כלל זניחה בהשוואה להשהיה שנובעת מאורך הסיבים.
- זמן האחזור ממיקום הקישור דרך הרשת של ספק שירותי הענן האחר לאזור שבו מתארחים המשאבים בספק שירותי הענן.
למרות שאין הבטחות לגבי זמן האחזור, הפתרון הזה בדרך כלל מאפשר את זמן האחזור הנמוך ביותר ואת מהירויות ההעברה הגבוהות ביותר בין Google Cloud לבין סביבות ענן אחרות באמצעות כתובות IP פרטיות.
אבטחה
כברירת מחדל, תעבורת נתונים דרך Dedicated Interconnect לא מוצפנת. כדי לאבטח את התעבורה, אפשר לפרוס HA VPN over Cloud Interconnect בצד Google Cloud של החיבור. ספקי CSP אחרים מאפשרים להשתמש בשירות ה-VPN המנוהל שלהם דרך חיבור רשת; לדוגמה, אפשר להשתמש ב-AWS Site-to-Site VPN דרך AWS Direct Interconnect. אפשרות אחרת היא להשתמש במכשיר וירטואלי שמצפין את התנועה בצד של ספק שירותי הענן האחר.
אפשרות נוספת היא להצפין את התנועה בשכבת האפליקציה במקום להשתמש ב-VPN.
אמינות והסכם רמת שירות (SLA)
כשמשתמשים ב-Dedicated Interconnect עם יתירות, Google מציעה הסכמי רמת שירות (SLA) חודשיים של 99.9% עד 99.99%, בהתאם לטופולוגיה שנבחרה. אין הסכם SLA על חיבור Dedicated Interconnect יחיד.
למידע נוסף, אפשר לעיין במסמכי ה-SLA של ספק ה-CSP האחר לגבי מוצר הקישוריות שלו, למשל AWS Direct Connect SLA או Azure SLA for ExpressRoute.
יכול להיות שמתקן לאחסון ואירוח שרתים (colocation facility) או ספק החומרה של ציוד הניתוב הפיזי יציעו גם הסכמי רמת שירות (SLA) על השירותים שלהם.
תמחור
בצד Google Cloud יש תשלום חודשי על כל יציאת Dedicated Interconnect ועל כל צירוף ל-VLAN שמתחבר לסביבת VPC. התנועה שיוצאת דרך Dedicated Interconnect מחויבת בשיעור נמוך יותר מהתנועה באינטרנט. מידע נוסף זמין בדף התמחור של Dedicated Interconnect.
כדי לראות את המחירים של מוצר הקישוריות של ספק CSP אחר, אפשר לעיין בדף המחירים שלו, למשל המחירים של AWS Direct Connect או המחירים של Azure ExpressRoute. בדרך כלל, התמחור כולל גם חיוב חודשי על הקישוריות וחיובים על העברת נתונים דרך הקישוריות, בשיעור נמוך יותר מאשר באינטרנט.
בנוסף, צריך לקחת בחשבון את העלויות של שירותי מתקן לאחסון ואירוח שרתים (colocation facility) שמספק מקום, חשמל וחיבורים פיזיים לשתי סביבות הענן, וגם את העלויות של חוזי שירות שוטפים עם הספק עבור ציוד הניתוב הפיזי. אם אי אפשר ליצור את החיבור בין שני ספקי הענן באותו מתקן וצריך לרכוש קישוריות בין מתקנים, המחירים של השירותים האלה עשויים להיות גבוהים בהרבה.
חיבורים מנוהלים של Cross-Cloud Interconnect
אתם יכולים לחבר את רשתות ה-VPC שלכם לרשתות וירטואליות בספק CSP אחר דרך רשת ה-fabric של Google. במובן מסוים, ההגדרה הזו פועלת כמו Partner Interconnect, אבל עם הסכם SLA של Google שמכסה גם את הרשתות של Google וגם את החיבורים עצמם. Google Cloud
התרשים הבא מציג הגדרה של Cross-Cloud Interconnect עם מספר החיבורים המינימלי.
המסלולים מועברים בין Cloud Router לבין השער בצד של ספק שירותי הענן השני דרך רשת ה-fabric של Google. תעבורת הנתונים עוברת דרך ה-fabric הזה בין Google Cloud לבין ספק שירותי הענן השני.
הטמעה
כשקונים Cross-Cloud Interconnect, Google מספקת חיבור פיזי ייעודי בין הרשת של Google לבין הרשת של ספק אחר של שירותי ענן. אתם יכולים להשתמש בחיבור הזה כדי ליצור קישור בין רשת הענן הווירטואלי הפרטי (VPC) שלכם Google Cloud לבין רשת שמארח ספק שירותי ענן נתמך.
אחרי הקצאת הקישור, Google תומכת בקישור עד שהוא מגיע לרשת של ספק שירותי הענן האחר. Google לא מבטיחה זמן פעולה רציף של ספק שירותי הענן האחר. עם זאת, Google נשארת איש הקשר הראשי לכל השירות, ותעדכן אתכם אם תצטרכו לפתוח פנייה לתמיכה אצל ספק שירותי הענן האחר.
כדי להשתמש בפתרון הזה, צריך לפעול לפי תהליך ההגדרה של ספק ה-CSP השני, כולל בחירת המקום שבו שתי הרשתות יתחברו. יש תמיכה רק ב-CSPs מסוימים.
אתם יכולים להתחבר באמצעות Cross-Cloud Interconnect בלבד, או להגדיר את Cross-Cloud Interconnect כ-Network Connectivity Center. Network Connectivity Center מאפשר לכם לחבר מיקומים מקומיים, רשתות VPC ועננים אחרים באמצעות ניהול מרכזי.
אם יש חפיפה בין מרחבי כתובות ה-IP בשני סביבות ה-CSP, אפשר להפעיל Hybrid NAT בחיבור.
מהירות העברה וזמן אחזור
הפתרון הזה מציע קיבולת ייעודית בין Google Cloud לבין ספק CSP אחר. בצד Google Cloud , אפשר להשתמש ב-Dedicated Interconnect באמצעות זוג אחד או יותר של חיבורים פיזיים של 10Gbps או 100Gbps.
ההשהיה של הפתרון הזה היא סכום הערכים הבאים:
- זמן האחזור בין האזור שבו המשאבים מתארחים ב-Google Cloud לבין המיקום ב-Cloud אחר.
- השהיה בין מיקום קצה של Google לבין מיקום קצה של ספק שירותי הענן האחר (לרוב באותו מתקן)
- זמן האחזור ממיקום הקצה של ספק שירותי הענן האחר שבו נפרס Cross-Cloud Interconnect לאזור שבו מתארחים המשאבים בספק שירותי הענן.
למרות שאין הבטחות לגבי זמן האחזור, הפתרון הזה בדרך כלל מאפשר את זמן האחזור הנמוך ביותר ואת מהירויות ההעברה הגבוהות ביותר ביןGoogle Cloud לבין סביבות ענן אחרות באמצעות כתובות IP פרטיות.
אבטחה
מכיוון שהתעבורה ב-Cross-Cloud Interconnect לא מוצפנת, מומלץ להשתמש בהצפנה בשכבת האפליקציה לתעבורה רגישה.
אם צריך להצפין את כל התעבורה, מכשירים וירטואליים שזמינים אצל Google Cloud שותפים ב-Cloud Marketplace יכולים לספק פתרונות להצפנת התעבורה לסביבה של ספק שירותי הענן האחר.
אמינות והסכם רמת שירות (SLA)
שירות Cross-Cloud Interconnect משתמש בהסכם רמת השירות (SLA) של Cloud Interconnect. כדי לעמוד בדרישות של ה-SLA, בהגדרת Cross-Cloud Interconnect צריך להשתמש בזוג חיבורים אחד או יותר, כפי שמתואר בקטע הסכם רמת שירות בסקירה הכללית של Cross-Cloud Interconnect.
הסכם ה-SLA מכסה את כל מה שקורה בצד של Google עד לקצה של הרשת של ספק הענן השני. הוא לא מכסה את הרשת של ספק הענן השני. למידע נוסף, אפשר לעיין במסמכי התיעוד של ספק הענן השני בנושא הסכם ה-SLA על מוצר הקישוריות שלו. לדוגמה, AWS Direct Connect SLA או Azure SLA for ExpressRoute.
תמחור
יש תשלום שעתי על כל חיבור Cross-Cloud Interconnect ועל כל צירוף ל-VLAN שמתחבר לסביבת VPC. תעבורת נתונים שיוצאת דרך Cross-Cloud Interconnect מחויבת בתעריף נמוך יותר מתעבורת נתונים באינטרנט. למידע נוסף, אפשר לעיין בתמחור של Cross-Cloud Interconnect.
כדי לראות את המחירים של מוצר הקישוריות של ספק CSP אחר, אפשר לעיין בדף המחירים שלו, למשל המחירים של AWS Direct Connect או המחירים של Azure ExpressRoute. בדרך כלל יש חיוב חודשי על הקישוריות. החיובים על העברת נתונים דרך הקישוריות בדרך כלל נמוכים יותר מהחיובים על העברת נתונים באינטרנט.
אין עלויות נפרדות למיקומי קישוריות או לציוד.
השוואה בין האפשרויות
האפשרויות שמוצגות שונות זו מזו במהירות, בזמינות, במורכבות, באבטחה ובמחיר. כדאי לבדוק היטב את כל האפשרויות בהתאם לצרכים שלכם.
בתרשים הזרימה הבא מוסבר תהליך הבחירה של אחד מהפתרונות שמוזכרים במאמר הזה.
בדרך כלל אנחנו יכולים להמליץ על האפשרויות הבאות:
- במקרים רבים שבהם מתבצע חילוף נתונים מדי פעם או בנפח נמוך, והעברת הנתונים לא קריטית, העברת נתונים באינטרנט היא האפשרות הפשוטה ביותר, והיא עדיין מספקת זמן אחזור נמוך יחסית ורוחב פס גבוה.
- אם נדרשת הצפנה או העברה של כמויות קטנות יותר של נתונים באמצעות כתובות IP פרטיות, מומלץ להשתמש ב-Cloud VPN ובשירות VPN מנוהל בצד של ספק שירותי הענן השני.
- אם מעבירים כמויות גדולות יותר של נתונים, שימוש ב-Partner Interconnect עם שותף שמופעל בו multicloud מספק כמה יתרונות: קיבולת ייעודית, עלות נמוכה יותר להעברת נתונים, ובאופן שתלוי בטופולוגיה, הסכם רמת שירות (SLA) לכל חלק בפתרון. הקיבולת של Partner Interconnect היא בדרך כלל פחות מ-10Gbps לכל חיבור.
- אם אתם מחברים את הציוד המקומי שלכם לכמה עננים, שימוש ב-Dedicated Interconnect דרך שרת POP משותף הוא אפשרות נפוצה. עם זאת, היא מורכבת יותר כי צריך לנהל את החומרה שלכם ואת הקשרים עם מתקן לאחסון ואירוח שרתים (colocation facility). אלא אם כבר יש לכם את התשתית הנדרשת, הפתרון הזה מתאים רק למקרים שבהם קצב העברת הנתונים האופייני הוא 10Gbps ומעלה.
- אם אתם לא רוצים להתמודד עם העומס של ניהול חיבורים צולבים וציוד ניתוב בנקודות PoP מרוחקות, Cross-Cloud Interconnect מספק פתרון מנוהל שבו Google מטפלת בכל זה בשבילכם.
המאמרים הבאים
- מומלץ לעיין בסדרה בנושא דפוסים ושיטות מומלצות לשימוש בענן היברידי ובסביבות מרובות עננים.
- כדאי להעמיק את הקריאה ולהכיר דוגמאות לארכיטקטורות, תרשימים ושיטות מומלצות בנושאי Google Cloud. כל אלה זמינים במרכז הארכיטקטורה של Cloud.