הגדרת קישוריות פרטית להעברות ל-Snowflake

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

בקטעים הבאים מפורטים השלבים הנדרשים להגדרת קישוריות פרטית לפני שיוצרים העברה ב-Snowflake.

העברות פרטיות נתמכות במופעי Snowflake שמתארחים ב-Amazon Web Services ‏ (AWS), ב-Microsoft Azure וב- Google Cloud.

יצירת קישור פרטי ל-Snowflake

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

AWS

מגדירים את AWS PrivateLink כדי לקשר את חשבון Snowflake לחשבון AWS. חשבון AWS שלכם צריך להכיל את קטגוריית הביניים של Amazon S3 שנדרשת להעברה ב-Snowflake.

Azure

מגדירים את Azure Private Link כדי לחבר את Azure Virtual Network ‏ (VNet) אל Snowflake VNet ב-Azure. חשבון Azure שלכם צריך לכלול את מאגר Blob staging שנדרש להעברה ב-Snowflake.

Google Cloud

הגדרה של Google Cloud Private Service Connect כדי לחבר את רשת הענן הווירטואלי הפרטי (VPC) שלכם Google Cloud. ב-Google Cloud שלכם צריכה להיות קטגוריית אחסון זמני ב-Cloud Storage שנדרשת להעברה ל-Snowflake.

הגדרה של Cross-Cloud Interconnect או HA VPN

להגדיר Cross-Cloud Interconnect או HA VPN מ-AWS או מ-Azure. לא צריך לבצע את השלב הזה בחשבונות Snowflake שמארחים ב-Google Cloud.

AWS

רשת VPN בזמינות גבוהה מאפשרת להעביר נתונים דרך מנהרת VPN מוצפנת. כדי להשתמש ב-HA VPN להעברה פרטית של Snowflake, אפשר לעיין במאמר בנושא יצירת חיבורי HA VPN בין Google Cloud לבין AWS.

חיבור Cross-Cloud Interconnect יוצר קישור פרטי ייעודי בין ספקי ענן, והוא מתאים להעברות נתונים גדולות עם דרישות של זמן אחזור נמוך. כדי להשתמש ב-Cross-Cloud Interconnect להעברה פרטית של Snowflake, אפשר לעיין במאמר חיבור ל-AWS.

Azure

רשת VPN בזמינות גבוהה מאפשרת להעביר נתונים דרך מנהרת VPN מוצפנת. כדי להשתמש ב-HA VPN להעברה פרטית של Snowflake, אפשר לעיין במאמר בנושא יצירת חיבורי HA VPN בין Google Cloud לבין Azure.

חיבור Cross-Cloud Interconnect יוצר קישור פרטי ייעודי בין ספקי ענן, והוא מתאים להעברות נתונים גדולות עם דרישות של זמן אחזור נמוך. כדי להשתמש ב-Cross-Cloud Interconnect להעברה פרטית של Snowflake, אפשר לעיין במאמר חיבור ל-Azure.

יצירת מכונה וירטואלית של שרת Proxy

כדי להשלים חיבור פרטי, נדרשת מכונה וירטואלית של שרת proxy כדי להשלים את החיבור בין מקורות הנתונים בלי שהנתונים יגיעו לאינטרנט הציבורי. השלב הזה נדרש למופעי Snowflake שמתארחים ב-AWS,‏ Azure או Google Cloud.

כדי ליצור ולהגדיר מכונה וירטואלית (VM) של שרת proxy להעברה פרטית של Snowflake:

1. יוצרים מכונה וירטואלית אחת או יותר של Compute Engine ברשת ה-VPC של הצרכן.
2. מורידים תוכנת TCP Proxy, כמו HAProxy או Nginx, ומגדירים את הפרטים הבאים:
   1. מציינים יציאה. לדוגמה, 443.
   2. מעבירים את כל תנועת ה-TCP הנכנסת לשם המארח הפרטי וליציאה במופע של Snowflake.
3. מגדירים את המכונות הווירטואליות כך שיבצעו התאמה של שם המארח הפרטי של Snowflake באמצעות ה-DNS שהוגדר ברשת ה-VPC של הצרכן.
4. כדי להגדיר מאזן עומסים פנימי להעברת סיגנל ללא שינוי:
   1. קיבוץ מכונות וירטואליות של שרת proxy לקבוצת מופעי מכונה מנוהלים (MIG).
   2. איך מגדירים מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי עם קבוצות של מכונות וירטואליות בתור בק-אנד

יצירת קובץ מצורף של שירות

שימוש ב-Private Service Connect כדי ליצור קובץ מצורף לרשת ולפרסם את השירות. השלב הזה נדרש למופעי Snowflake שמתארחים ב-AWS,‏ Azure או Google Cloud.

ה-Service Attachment צריך להיות באותו אזור כמו מערך הנתונים ב-BigQuery.

אם השירות שלכם משתמש באישור מפורש (connection-preference מוגדר כ-ACCEPT_MANUAL), לחשבון השירות שמשמש להעברת נתונים פרטיים ב-Snowflake צריכות להיות הרשאות ה-IAM הבאות:

• compute.serviceAttachments.get
• compute.serviceAttachments.update
• compute.regionOperations.get

אחרי שיוצרים את חיבור השירות, רושמים את ה-URI של חיבור השירות. תצטרכו את ה-URI הזה כשתיצרו את הגדרות ההעברה של Snowflake.

ליצור נקודות קצה

יוצרים נקודת קצה בחשבון AWS או Azure. לא צריך לבצע את השלב הזה בחשבונות Snowflake שמארחים ב-Google Cloud.

AWS

ב-AWS, יוצרים נקודת קצה (endpoint) של VPC שמתחברת ל-Amazon S3. מידע נוסף זמין במאמר גישה לשירות AWS באמצעות נקודת קצה של ממשק VPC.

Azure

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

‫Storage Transfer Service דורש את נקודת הקצה *.blob.core.windows.net. אין תמיכה בנקודת הקצה *.dfs.core.windows.net.

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

יצירת מאזן עומסי רשת

ב- Google Cloud, מגדירים מאזן עומסי רשת פנימי אזורי בשרת proxy עם קישוריות היברידית. הפעולה הזו מספקת כתובת IP פנימית שמוגבלת ללקוחות שפועלים באותה רשת VPC כמו מאזן העומסים, ומנתבת תעבורה לנקודות הקצה של S3 VPC או לנקודות הקצה הפרטיות של Azure Storage שיצרתם בקטע הקודם.

צריך ליצור את מאזן העומסים באותו פרויקט ובאותה רשת VPC שבהם נמצא צירוף ה-VLAN שמקושר ל-Cloud Interconnect. החיבור עצמו יכול להיות בפרויקט אחר באותו ארגון, אבל הצירוף חייב להיות באותו VPC ובאותו אזור כמו איזון העומסים.

• הגדרה של מאזן עומסי רשת אזורי פנימי לשרת proxy עם קישוריות היברידית

מציינים את כתובת ה-IP של נקודת הקצה של S3 VPC או של נקודת הקצה הפרטית של Azure Storage כשמגיעים לשלבים שמסומנים בתווית Add endpoints to the hybrid connectivity NEG (הוספת נקודות קצה ל-NEG של קישוריות היברידית).

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

אימות החיבור

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

כדי לעשות את זה:

1. יוצרים מכונה וירטואלית ב-Compute Engine באותה רשת VPC שבה נמצא איזון העומסים.

2. במכונה הווירטואלית, משתמשים ב-curl כדי לבדוק את הקישוריות לכתובת ה-IP ולפורט של מאזן העומסים:

   curl -v --resolve HOSTNAME:PORT:LOAD_BALANCER_IP https://HOSTNAME
   

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

   • ‫HOSTNAME הוא שם המארח של ספק האחסון של המקור.
     • ב-AWS S3, משתמשים בנקודת הקצה של S3 API לאזור של הקטגוריה, לדוגמה s3.us-west-1.amazonaws.com.
     • ב-Azure Storage, משתמשים בנקודת הקצה של ה-blob בחשבון האחסון, לדוגמה mystorageaccount.blob.core.windows.net.
   • ‫PORT היא היציאה שהגדרתם בכלל ההעברה של מאזן העומסים, בדרך כלל 443.
   • ‫LOAD_BALANCER_IP היא כתובת ה-IP של חזית מאזן העומסים.

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

רישום ה-NLB

רושמים את ה-NLB ב-Service Directory. ‫BigQuery משתמש ב-Service Directory כדי לזהות את הכתובת של מאזן העומסים ולהתחבר אליו ישירות.

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

אחרי שיוצרים את השירות, רושמים את הקישור העצמי שלו. הפורמט הוא projects/{project_id}/locations/{location}/namespaces/{namespace}/services/{service}. תצטרכו את הערך הזה כשתיצרו את משימת ההעברה.

הכנת קטגוריית אחסון זמנית

כדי להשלים העברת נתונים מ-Snowflake, צריך ליצור bucket זמני ואז להגדיר אותו כך שתהיה ל-Snowflake גישת כתיבה אליו.

בוחרים באחת מהאפשרויות הבאות:

AWS

בחשבונות Snowflake שמארחים ב-AWS, צריך ליצור מאגר Amazon S3 כדי להכין את נתוני Snowflake לפני הטעינה שלהם ל-BigQuery.

1. יוצרים קטגוריה ב-Amazon S3.

2. יוצרים ומגדירים אובייקט של שילוב אחסון ב-Snowflake כדי לאפשר ל-Snowflake לכתוב נתונים בקטגוריה של Amazon S3 כשלב חיצוני.

כדי לאפשר גישת קריאה לקטגוריית Amazon S3, צריך גם לבצע את הפעולות הבאות:

1. יוצרים משתמש ייעודי ב-Amazon IAM ומעניקים לו את מדיניות AmazonS3ReadOnlyAccess.

2. יוצרים זוג מפתחות גישה לאמזון עבור משתמש IAM.

Azure

בחשבונות Snowflake שמארחים ב-Azure, צריך ליצור מאגר Azure Blob Storage כדי להכין את נתוני Snowflake לפני שהם נטענים ל-BigQuery.

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

כדי לאפשר גישת קריאה למאגר Azure, צריך ליצור טוקן SAS בשבילו.

Google Cloud

בחשבונות Snowflake שמארחים ב- Google Cloud, צריך ליצור קטגוריה ב-Cloud Storage כדי להכין את נתוני Snowflake לפני שהם נטענים ל-BigQuery.

1. יצירת קטגוריה של Cloud Storage
2. יוצרים ומגדירים אובייקט של שילוב אחסון ב-Snowflake כדי לאפשר ל-Snowflake לכתוב נתונים בקטגוריית Cloud Storage כשלב חיצוני.

3. כדי לאפשר גישה לקטגוריית הביניים, צריך להקצות לסוכן השירות של DTS את התפקיד roles/storage.objectViewer באמצעות הפקודה הבאה:

   gcloud storage buckets add-iam-policy-binding gs://STAGING_BUCKET_NAME \
     --member=serviceAccount:[e-mail] \
     --role=roles/storage.objectViewer

יצירת הגדרות העברה פרטיות ב-Snowflake

יוצרים את ההעברה ב-Snowflake. כשמגדירים את ההגדרות של ההעברה, מבצעים את הפעולות הבאות:

המסוף

• בשדה Use Private Network (שימוש ברשת פרטית), בוחרים באפשרות True (נכון).
• בשדה PSC Service Attachment (צירוף שירות PSC), מזינים את מזהה המשאבים האחיד (URI) של צירוף השירות. מידע על איתור ה-URI של קובץ השירות מצורף זמין במאמר הצגת פרטים של שירות שפורסם. מזהה ה-URI של קובץ השירות הוא בפורמט projects/PROJECT_ID/regions/REGION/serviceAttachments/SERVICE_ATTACHMENT.
• בשדה Private Network Service (שירות רשת פרטי), מזינים את הקישור העצמי של שירות NLB. הפורמט הוא projects/PROJECT_ID/locations/LOCATION/namespaces/NAMESPACE/services/SERVICE_NAME.
• ה-URI של קטגוריית הביניים שרוצים להשתמש בה להעברה:
  • בחשבון Snowflake שמארח ב-AWS, צריך לציין URI של קטגוריית Amazon S3 ופרטי גישה.
  • במקרה של Snowflake שמארח ב-Azure, נדרשים חשבון ומאגר ב-Azure Blob Storage.
  • בחשבון Snowflake שמארחGoogle Cloud, צריך לציין Cloud Storage bucket URI.

• בקטע Cloud Provider (ספק שירותי ענן), בוחרים באפשרות AWS,‏ AZURE או GCP בהתאם לספק שירותי הענן שמארח את חשבון Snowflake.

  AWS

  • בשדה Amazon S3 URI (כתובת URI של Amazon S3), מזינים את כתובת ה-URI של קטגוריית Amazon S3 שבה רוצים להשתמש כקטגוריית ביניים.
  • בשדות מזהה מפתח הגישה ומפתח גישה סודי, מזינים את זוג מפתחות הגישה.

  Azure

  • בשדות שם חשבון האחסון ב-Azure והמאגר בחשבון האחסון ב-Azure, מזינים את שם חשבון האחסון ושם המאגר ב-Azure Blob Storage שבהם רוצים להשתמש כמאגר זמני.
  • בקטע SAS Token, מזינים את טוקן ה-SAS שנוצר עבור המאגר.

  Google Cloud

  • בקטע GCS URI, מזינים את ה-URI של Cloud Storage שבו רוצים להשתמש כקטגוריית ביניים.

BQ

• לפרמטר use_private_network, מגדירים את הערך TRUE.
• בפרמטר service_attachment, מציינים את מזהה המשאבים האחיד (URI) של קובץ השירות. מידע על איתור ה-URI של קובץ השירות מצורף זמין במאמר הצגת פרטים של שירות שפורסם. מזהה ה-URI של קובץ השירות הוא בפורמט projects/PROJECT_ID/regions/REGION/serviceAttachments/SERVICE_ATTACHMENT.
• בפרמטר private_network_service, מציינים את הקישור העצמי של שירות ה-NLB. הפורמט הוא projects/PROJECT_ID/locations/LOCATION/namespaces/NAMESPACE/services/SERVICE_NAME.
• ‫cloud_provider: מזינים AWS או AZURE או GCP בהתאם לספק הענן שמארח את חשבון Snowflake.
• ‫staging_s3_uri: מזינים את ה-URI של קטגוריית S3 שבה רוצים להשתמש כקטגוריית ביניים. נדרש רק אם cloud_provider הוא AWS.
• ‫aws_access_key_id: מזינים את זוג מפתחות הגישה. נדרש רק אם cloud_provider הוא AWS.
• ‫aws_secret_access_key: מזינים את זוג מפתחות הגישה. נדרש רק אם cloud_provider הוא AWS.
• ‫azure_storage_account: מזינים את השם של חשבון האחסון שרוצים להשתמש בו כקטגוריית אחסון זמנית. נדרש רק אם cloud_provider הוא AZURE.
• ‫staging_azure_container: מזינים את המאגר ב-Azure Blob Storage שבו רוצים להשתמש כקטגוריית אחסון זמני. נדרש רק אם cloud_provider הוא AZURE.
• ‫azure_sas_token: מזינים את טוקן ה-SAS. נדרש רק אם cloud_provider הוא AZURE.
• ‫staging_gcs_uri : מזינים את ה-URI של Cloud Storage שבו רוצים להשתמש כקטגוריית אחסון זמני. נדרש רק אם cloud_provider הוא GCP.