העברה מנוהלת היא תכונה אוטומטית שעוזרת להעביר נתונים מ-Hive Metastore בניהול עצמי לשירות Dataproc Metastore, בלי השבתה משמעותית (שנקראת גם יום מעבר).
ארכיטקטורה של העברה מנוהלת
בתרשים הבא מוצגת הארכיטקטורה ברמה גבוהה של העברה מנוהלת.
תהליך מיגרציה מנוהל
כדי להשלים העברה מנוהלת, השירות מפעיל שני תהליכי העברה – התחלת ההעברה והשלמת ההעברה. אפשר לבטל את ההעברה בכל שלב באמצעות התהליך ביטול ההעברה. יש גם מספר פקודות תפעוליות שאפשר להריץ, אבל הן לא נדרשות להשלמת ההעברה. לדוגמה, list migrations או delete migrations.
במהלך התהליך הזה, השירות עובר גם בין מצבי העברה שונים ושלבי העברה שונים. המצבים והשלבים האלה מייצגים את התהליכים שמתרחשים ברקע. לדוגמה, המצב MIGRATING מציין שהשירות מעביר נתונים באופן פעיל ממסד הנתונים של Cloud SQL אל Dataproc Metastore.
התחלת ההעברה
Dataproc Metastore יוצר חיבור עם מופע Cloud SQL של כתובת IP פרטית. אחרי יצירת החיבור, Dataproc Metastore משתמש במופע Cloud SQL כמסד הנתונים העורפי של Hive Metastore (HMS). הוא גם נשאר המקור המהימן לנתונים שלכם במהלך ההעברה. פעולות קריאה וכתיבה של מטא-נתונים עדיין מתרחשות ב-Cloud SQL כשההעברה פעילה.
צינור לסימון נתונים שהשתנו (CDC) מופעל. הצינור הזה שומר על סנכרון בין מופע Cloud SQL בפרויקט שלכם לבין Spanner בפרויקט המנוהל של Dataproc Metastore. המשמעות היא שכל השינויים במסד הנתונים של HMS במכונת Cloud SQL מתועדים באמצעות Datastream ונכתבים במסד הנתונים של Dataproc Metastore Spanner.
אחרי שהתהליך של התחלת ההעברה יסתיים בהצלחה, תוכלו להתחיל להפנות עומסי עבודה של נתונים אל Dataproc Metastore. בשלב הזה, Cloud SQL עדיין משמש כמקור המידע האמין של הנתונים.
השלמת ההעברה
אחרי שמסיימים להעביר את עומסי העבודה ל-Dataproc Metastore, אפשר להשלים את המיגרציה. כשמפעילים תהליך של העברה מלאה, קורה הדבר הבא:
- מערכת Dataproc Metastore עוברת למצב קריאה בלבד עד שתהליך ההעברה המלא מסתיים.
- השידור של CDC מעביר את כל הנתונים שנמצאים בתהליך אל Dataproc Metastore.
- Dataproc Metastore מתחבר ל-Spanner ומתנתק מ-Cloud SQL. מעכשיו, Dataproc Metastore משמש כמקור האמת לנתוני HMS.
שיקולים לגבי שרתי proxy וצינורות עיבוד נתונים
שרתי proxy
Dataproc Metastore משתמש בשרת proxy ל-Cloud SQL Auth שמשורשר לשרת proxy מסוג SOCKS5 כדי להתחבר למכונת Cloud SQL עם כתובת IP פרטית. שרתי ה-proxy של SOCKS5 נחשפים דרך קובץ מצורף לשירות, כפי שמוצג בתרשים הארכיטקטורה הקודם.
לכל העברה נדרשת תת-רשת NAT ייעודית. הסיבה לכך היא שרשת משנה של NAT לא יכולה לכלול יותר מחיבור שירות אחד.
כדי למנוע בעיות של זמן אחזור בין אזורים, צריך לספק רשתות משנה שנמצאות באותו אזור כמו מכונת Cloud SQL כדי לארח את פרוקסי SOCKS5. לדוגמה,
proxy_subnetו-nat_subnet.
צינור לסימון נתונים שהשתנו (CDC)
צינור עיבוד הנתונים של Change Data Capture (לכידת נתונים לשינוי) משתמש ב-VPC Peering כדי ליצור חיבור בין Datastream לבין Cloud SQL עם כתובת IP פרטית.
לכל העברה נוצר חיבור פרטי חדש ונוצר חיבור חדש של קישור בין רשתות שכנות (peering).
ברשת ה-VPC שמארחת את מופע Cloud SQL יש מספר חיבורי Peering ששווה למספר ההעברות הפעילות. מוודאים שלרשת ה-VPC יש את היכולת לארח את כל חיבורי ה-Peering הנדרשים.