שכפול נתונים מ-Spanner ל-Spanner Omni

במאמר הזה מתוארים דפוסים, שלבי הגדרה והנחיות תפעוליות להגדרת טופולוגיות של תוכנית התאוששות מאסון (DR) בין Spanner מנוהל ב-Google Cloud לבין Spanner Omni בסביבה חיצונית כמו AWS או מרכז נתונים מקומי.

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

סקירה כללית של הארכיטקטורה

בטופולוגיה של תוכנית התאוששות מאסון חוצת-עננים, Spanner ב-Google Cloud משמש כמסד הנתונים הראשי, ו-Spanner Omni משמש כפריסה במצב המתנה או כאתר משני לתוכנית התאוששות מאסון. אתם יכולים לשכפל שינויים בטרנזקציות באופן רציף באמצעות סנכרון שינויים בזרמי נתונים.

בטבלה הבאה מוצגת השוואה בין היכולות, התפקידים והגבולות התפעוליים של מסד הנתונים בפריסה ראשית של Spanner לבין פריסה משנית של Spanner Omni ב-AWS.

השוואה בין פריסות ראשיות של Spanner לבין פריסות משניות של Spanner Omni

יכולת או מאפיין	האתר הראשי: Spanner ב- Google Cloud	אתר משני: Spanner Omni ב-AWS
מודל פריסה	שירות שמנוהל במלואו ב- Google Cloud.	תוכנה בניהול עצמי ב-AWS, כמו Amazon Elastic Compute Cloud (Amazon EC2) או Amazon Elastic Kubernetes Service (Amazon EKS).
הסכם רמת שירות לזמינות	עד 99.999% להגדרות במספר אזורים ו-99.99% להגדרות אזוריות. מידע נוסף מופיע בהסכם רמת השירות של Spanner.	מנוהל על ידי הלקוח, תלוי בתשתית ובטופולוגיה שלכם.
מצב שכפול	רפליקציה סינכרונית מבוססת-Paxos בין תחומים ואזורים.	סימון נתונים שהשתנו (CDC) באופן אסינכרוני וכמעט בזמן אמת באמצעות סנכרון שינויים בזרמי נתונים.
יעד להתאוששות מאסון (RPO)	קרוב לאפס במכונה המנוהלת.	פחות משנייה עד כמה שניות בין גבולות הענן, בהתאם לקצב העברת הנתונים בצינור עיבוד הנתונים ולזמן האחזור ברשת.
יעד זמן ההתאוששות (RTO)	מעבר מיידי ואוטומטי למצב של יתירות כשל בין רפליקות.	תלוי ב-DNS ובמדריך ההפעלה למעבר בין תנועות.
שכבת התחבורה הציבורית ברשת	קישור בין רשתות VPC שכנות (peering) או Cloud Interconnect.	‫Cross-Cloud Interconnect שמחובר ל-AWS Direct Connect.
יעד האחסון לגיבוי	גיבויים של Spanner בניהול Google, שאפשר לשחזר רק ב-Spanner מנוהל.	‫Cloud Storage או Amazon Simple Storage Service (Amazon S3), שאפשר לשחזר רק ל-Spanner Omni.

לפני שמתחילים

לפני שמגדירים רפליקציה בין Spanner ל-Spanner Omni, צריך לוודא שהסביבה עומדת בדרישות הבאות:

• הקצאת קיבולת תואמת ביעד: מתאימים את הגודל של פריסת Spanner Omni ביעד לקיבולת הקלט/פלט של המעבד, הזיכרון והאחסון של מכונת Spanner הראשית. אם הפריסה קטנה מדי, יכול להיות שיהיה עיכוב ברפליקציה, ושאשכול הגיבוי לא יוכל לטפל בעומסי העבודה בזמן מעבר לגיבוי במקרה של כשל. מידע נוסף זמין במאמר דרישות המערכת.
• סנכרון סכימות של מסדי נתונים ונתוני בסיס: יוצרים את מסד הנתונים והטבלאות של היעד ב-Spanner Omni באמצעות אותו ניב SQL, ‏ GoogleSQL או PostgreSQL, והגדרות סכימה כמו במסד הנתונים של Spanner במקור. אי אפשר לשחזר גיבוי מנוהל של Spanner ב-Spanner Omni, לכן צריך לייצא נתונים קיימים מ-Spanner לקובצי Avro ב-Cloud Storage ולייבא אותם ל-Spanner Omni. מידע נוסף מופיע במאמרים הבאים: סכימה ומודל נתונים, פיתוח באמצעות Spanner Omni, ייצוא מסדי נתונים מ-Spanner ל-Avro וייבוא וייצוא של נתונים.
• יצירת קישוריות לרשת פרטית: מגדירים ניתוב של רשת פרטית בין רשת ה-VPC של Google Cloud לבין הסביבה החיצונית, כדי שרכיבי ה-worker של הרפליקציה יוכלו להתחבר גם ל-Spanner וגם לנקודת הקצה של Spanner Omni gRPC. למידע נוסף, קראו את המאמר בחירת מוצרים של Network Connectivity ואת המאמר האצת הרפליקציה באמצעות Cross-Cloud Interconnect.

שכפול נתונים באופן רציף באמצעות סנכרון שינויים בזרמי נתונים

באפליקציות שדורשות המשכיות עסקית חוצת-עננים, סנכרון שינויים בזרמי נתונים ב-Spanner מוציא שינויים בנתוני טרנזקציות (פעולות INSERT, UPDATE ו-DELETE) לפי סדר חותמות הזמן של ה-commit. צינור עיבוד נתונים לרפליקציה רציפה קורא רשומות של שינויים מ-Spanner ב- Google Cloud וכותב אותן בפריסה של Spanner Omni.

שימוש בסנכרון שינויים בזרמי נתונים לרפליקציה חוצת-עננים מספק את היתרונות הבאים:

• מצב המתנה פעיל-סביל: שומר על רפליקה חמה ב-Spanner Omni שמוכנה לטפל בעומסי עבודה כשמפעילים יתירות כשל.
• רפליקציה סלקטיבית: אתם יכולים להגדיר את סנכרון השינויים בזרמי הנתונים כך שיעקוב אחרי מסד הנתונים כולו, או להגביל אותו לטבלאות ולעמודות ספציפיות כדי להפחית את עלויות ההעברה חוצת-עננים.
• התאמה בין דיאלקטים: מכיוון ש-Spanner Omni תומך באותם דיאלקטים של GoogleSQL ו-PostgreSQL ובאותה סמנטיקה של סכימה כמו Spanner, השאילתות של האפליקציה פועלות בלי שינוי אחרי המעבר החד למערכת אחרת (cutover).

שלב 1: יוצרים סנכרון שינויים בזרמי נתונים במסד הנתונים של המקור

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

CREATE CHANGE STREAM CHANGE_STREAM_NAME
FOR TABLE_NAMES
OPTIONS (
  retention_period = '7d',
  value_capture_type = 'NEW_ROW_AND_OLD_VALUES'
);

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

• ‫CHANGE_STREAM_NAME: השם של סנכרון השינויים בזרמי הנתונים, לדוגמה CsToOmniDrStream.
• ‫TABLE_NAMES: רשימה מופרדת בפסיקים של טבלאות למעקב, לדוגמה Customers, Orders, AccountBalances, או ALL כדי לעקוב אחרי כל הטבלאות במסד הנתונים.

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

שלב 2: פריסת צינור עיבוד נתונים של CDC

כדי להעביר שינויים בסטרימינג מ-Spanner ל-Spanner Omni, פורסים צינור עיבוד נתונים רציף של סימון נתונים שהשתנו (CDC) באמצעות Dataflow עם Apache Beam, או מריצים פודים מותאמים אישית של וורקרים ב-Google Kubernetes Engine ‏ (GKE) או ב-Amazon EKS.

צינור עיבוד נתונים של רפליקציה בסביבת ייצור מבצע את המשימות הבאות:

• קריאת מחיצות: שימוש ב-Spanner Change Streams API או במחבר Apache Beam SpannerIO כדי לקרוא רשומות של שינויים במחיצות דינמיות של סנכרון שינויים בזרמי נתונים. למידע נוסף, קראו את המאמרים מחיצות, רשומות ושאילתות של סנכרון שינויים בזרמי נתונים ועיבוד רשומות של סנכרון שינויים בזרמי נתונים באמצעות Dataflow.
• אגירה וסידור של מוטציות: יצירת רצפים וטרנזקציות באצווה לפי חותמות הזמן של ה-commit שלהן (commit_timestamp) לכל טווח מפתחות או טבלה, כדי לשמור על עקביות הטרנזקציות ולמקסם את קצב הכתיבה.
• כתיבה ב-Spanner Omni: מתחבר דרך gRPC לנקודת הקצה הפרטית של פריסת Spanner Omni ומחיל את השינויים באצווה. אם אתם משתמשים במחבר Apache Beam SpannerIO עם הצפנה, השתמשו ב-Apache Beam מגרסה 2.69.0 ואילך ל-TLS, או מגרסה 2.75.0 ואילך ל-Mutual TLS ‏ (mTLS). מידע נוסף זמין במאמרים שימוש ב-Apache Beam וב-SpannerIO כדי להתחבר ל-Spanner Omni ואימות והרשאה.
• מעקב אחרי השהיית הרפליקציה: מעקב אחרי ההפרש בין הזמן הנוכחי לבין ה-commit_timestamp של רשומות השינויים שעובדו, כדי שתוכלו לקבל התראות על עיכובים ברפליקציה.

אם אתם משתמשים ב-Dataflow או ב-Apache Beam, אתם צריכים להשתמש ב-Apache Beam Java SDK כי ה-Python SDK לא כולל מחבר לסנכרון שינויים בזרמי נתונים. בדוגמה הבאה ב-Python, שמתאימה לפודים מותאמים אישית של Worker, מוסבר איך להגדיר לקוח Spanner Omni באמצעות הצפנת TLS ולהחיל אצווה של סנכרון שינויים בזרמי נתונים על מסד נתונים של יעד. בעומסי עבודה גדולים, כדאי להוסיף לתור ולעבד באצווה מוטציות שלא חופפות, לפי סדר חותמות הזמן של ה-commit, בתהליכי worker מקבילים, במקום לבצע commit לרשומה אחת בכל פעם:

from google.cloud import spanner
from google.cloud.spanner_v1 import InstanceType

# Configure the Spanner Omni target client
omni_client = spanner.Client(
    client_options={"api_endpoint": "ENDPOINT"},
    instance_type=InstanceType.OMNI,
    ca_certificate="PATH_TO_CA_CERT",
)
# Spanner Omni uses "default" as the instance ID
omni_instance = omni_client.instance("default")
omni_database = omni_instance.database("DATABASE_ID")


def apply_cdc_mutations_to_omni(records):
    """Applies a batch of ordered change stream records to Spanner Omni."""

    def write_batch(transaction):
        for record in records:
            table_name = record["tableName"]
            mutation_type = record["mutationType"]  # INSERT, UPDATE, DELETE
            row_data = record.get("columnValues", {})

            if mutation_type in ("INSERT", "UPDATE"):
                transaction.insert_or_update(
                    table=table_name,
                    columns=list(row_data.keys()),
                    values=[list(row_data.values())],
                )
            elif mutation_type == "DELETE":
                key_columns = record["keyValues"]
                transaction.delete(
                    table=table_name,
                    keyset=spanner.KeySet(keys=[list(key_columns.values())]),
                )

    omni_database.run_in_transaction(write_batch)

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

• ‫ENDPOINT: נקודת הקצה הפרטית של gRPC והיציאה של מכונת Spanner Omni, לדוגמה spanner-omni.internal.example.com:15000.
• ‫PATH_TO_CA_CERT: הנתיב לקובץ האישור של רשות האישורים (CA) לפריסת Spanner Omni.
• ‫DATABASE_ID: המזהה של מסד הנתונים של היעד ב-Spanner Omni.

מידע נוסף על הגדרת חיבורי לקוחות זמין במאמר שימוש בספריית הלקוח של Python כדי להתחבר ל-Spanner Omni.

האצת הרפליקציה באמצעות Cross-Cloud Interconnect

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

בטבלה הבאה מוצגת השוואה בין מאפייני הרשת של חיבורים לאינטרנט הציבורי או ל-IPsec VPN לבין Cross-Cloud Interconnect.

השוואה בין אפשרויות להעברת נתונים ברשת לצורך רפליקציה חוצת-עננים

מדד הרשת	אינטרנט ציבורי או IPsec VPN	Cross-Cloud Interconnect
קיבולת הקישור	‫‎1.25 Gbps עד ‎3 Gbps לכל מנהרה.	רוחב פס אופטי ייעודי של ‎10 Gbps או ‎100 Gbps לכל קישור.
זמן האחזור והרעידות של הרשת	מסלולי מעבר משתנים ובלתי צפויים באינטרנט.	ניתוב פרטי דטרמיניסטי עם זמן אחזור קצר.
הסכם רמת שירות לזמינות	אין הסכם רמת שירות (SLA) לביצועים מקצה לקצה.	הסכם רמת שירות (SLA) עם זמינות של 99.9% או 99.99% כשמגדירים חיבורים מיותרים.
הצפנה של העברת נתונים	תקורה של IPsec ומגבלות קריפטוגרפיה של תוכנה.	הצפנת MACsec בקצב קו ל-Cloud Interconnect‏ (IEEE 802.1AE). מידע נוסף זמין במאמר סקירה כללית על MACsec ל-Cloud Interconnect.
עלויות העברת נתונים	תעריפים רגילים של תעבורת נתונים יוצאת (egress) באינטרנט.	תעריפים נמוכים יותר להעברת נתונים ב-Cloud Interconnect.

תהליך עבודה ברמה גבוהה להגדרת רשת

כדי להגדיר את Cross-Cloud Interconnect לצינור עיבוד הנתונים של הרפליקציה, מבצעים את השלבים הבאים:

1. הזמנת חיבורי Cross-Cloud Interconnect: מזמינים יציאות ראשיות ומיותרות של Cross-Cloud Interconnect במתקן לאחסון ואירוח שרתים (colocation facility) שמתאים למיקום של ספק שירותי הענן המרוחק. לדוגמה, מריצים את הפקודה gcloud compute interconnects create:

   gcloud compute interconnects create CONNECTION_NAME \
     --interconnect-type=DEDICATED \
     --link-type=CAPACITY \
     --requested-link-count=LINK_COUNT \
     --location=GOOGLE_CLOUD_LOCATION \
     --remote-location=REMOTE_LOCATION \
     --noc-contact-email=CONTACT_EMAIL
   

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

   • ‫CONNECTION_NAME: השם של חיבור Cross-Cloud Interconnect.
   • ‫CAPACITY: קיבולת הקישור, למשל LINK_TYPE_ETHERNET_10G_LR או LINK_TYPE_ETHERNET_100G_LR.
   • ‫LINK_COUNT: מספר הקישורים שצריך לבקש.
   • ‫GOOGLE_CLOUD_LOCATION: דומיין הזמינות של הקצה (edge) במיקום Google Cloud , לדוגמה iad-zone1-1.
   • ‫REMOTE_LOCATION: המיקום של ספק שירותי הענן המרוחק, לדוגמה aws-us-east-1.
   • ‫CONTACT_EMAIL: כתובת האימייל שלכם לפעולות ברשת.

   למידע נוסף, קראו את המאמרים בחירת המיקומים והזמנת יציאות AWS.

2. הגדרת Cloud Router וקישור בין רשתות שכנות באמצעות BGP: יוצרים צירופים ל-VLAN ומגדירים סשנים של Border Gateway Protocol ‏ (BGP) בין Cloud Router ברשת ה-VPC של Google Cloud לבין השער הפרטי הווירטואלי או שער החיבור הישיר בסביבת הענן המרוחקת. מידע נוסף זמין במאמרים סקירה כללית של Cloud Router, הגדרת המשאבים של Google Cloud והגדרת המשאבים של AWS.

3. אימות הפצת מסלולים: מוודאים שטבלאות המסלולים בשתי הרשתות מפיצות בלוקי CIDR שלא חופפים, כדי שה-workers של צינור עיבוד הנתונים של ה-CDC והצמתים של Spanner Omni יתקשרו רק באמצעות כתובות IP פרטיות. מידע נוסף זמין במאמר אימות החיבורים.

הוראות מלאות להגדרה מופיעות במאמר התחברות ל-Amazon Web Services במסמכי התיעוד של Cross-Cloud Interconnect.

רשימת משימות למעבר לגיבוי בעת כשל ולמדריך הפעלה

כשמבצעים מעבר או יתירות כשל מ-Spanner ב-Google Cloud ל-Spanner Omni, צריך לפעול לפי השלבים הבאים:

1. ניקוז שינויים בתהליך: מפסיקים את פעולות הכתיבה של האפליקציה במסד הנתונים הראשי של Spanner (אם הוא נגיש) ומוודאים שצינור עיבוד הנתונים של שכפול ה-CDC עיבד את כל הרשומות של סנכרון שינויים בזרמי נתונים עד לחותמת הזמן האחרונה של ה-commit.
2. הפניית חיבורי האפליקציות: מעדכנים את פרופילי ההגדרות של האפליקציות, את מחרוזות החיבור או את הסודות של Kubernetes כדי להתחבר לנקודות הקצה של Spanner Omni במקום ל-Spanner ב-Google Cloud.
3. עדכון ה-DNS וניתוב התנועה: מחליפים את רשומות ה-DNS או את היעדים של מאזן העומסים הגלובלי כדי לנתב את תנועת הלקוחות לשכבת האפליקציה ולמאזני העומסים שמוצבים לפני פריסת Spanner Omni.
4. סנכרון מחדש אחרי שחזור: אחרי שמשחזרים את הסביבה הראשית שלGoogle Cloud , הופכים את כיוון הרפליקציה לפני שחוזרים למצב הקודם. ניתן לתעד שינויים מ-Spanner Omni באמצעות סנכרון שינויים בזרמי נתונים של Spanner והמחבר Debezium כדי לפרסם שינויים ב-Apache Kafka, עם צרכן שמחיל אותם על Spanner. לחלופין, אתם יכולים לייצא את מסד הנתונים של Spanner Omni לקובצי Avro ב-Cloud Storage ולייבא אותם ל-Spanner. מידע נוסף זמין במאמרים ייבוא וייצוא של נתונים וייבוא קובצי Avro של Spanner.

המאמרים הבאים

• יצירה וניהול של גיבויים ב-Spanner Omni
• שחזור גיבוי של Spanner Omni
• ייבוא וייצוא של נתונים
• שימוש ב-Apache Beam וב-SpannerIO כדי להתחבר ל-Spanner Omni
• שימוש ב-Debezium כדי להתחבר ל-Spanner Omni