העברת נתוני Kafka אל Google Cloud באמצעות MirrorMaker 2.0

המאמר הזה יעזור לכם להעביר את עומסי העבודה של Apache Kafka אל השירות המנוהל של Google Cloud ל-Apache Kafka, שהוא שירות מנוהל בתוך Google Cloud.

השירות המנוהל ל-Apache Kafka עוזר לכם להפעיל את Apache Kafka ב- Google Cloud. בפתרון הזה, שמתואר במסמכים, מעבירים נתונים מאשכול חיצוני של Apache Kafka לאשכול של שירות מנוהל ל-Apache Kafka.

מידע נוסף על השירות המנוהל ל-Apache Kafka זמין במאמר סקירה כללית על השירות המנוהל ל-Apache Kafka.

מומלץ להשתמש ב-Apache Kafka‏ MirrorMaker 2.0 להעברה הזו.

‫MirrorMaker 2.0 הוא כלי לשכפול נתונים בין אשכולות של Apache Kafka בזמן אמת. אפשר להשתמש בה כדי להעביר נתונים, תוכנית התאוששות מאסון (DR), לבודד נתונים ולצבור נתונים.

מידע נוסף על MirrorMaker 2.0 זמין בקטע הבא.

מה זה MirrorMaker 2.0

‫MirrorMaker 2.0 משתמש במסגרת Kafka Connect כדי לשכפל נתונים בין אשכולות Kafka. ‫Kafka Connect היא מסגרת להזרמת נתונים בין אשכולות Kafka ומערכות אחרות. הוא פועל כצינור לעיבוד נתונים שניתן להתאמה ומהימן. המסגרת הזו מפשטת את השילוב של Kafka עם מערכות חיצוניות שונות, כמו מסדי נתונים, תורים של הודעות ואחסון אונליין, באמצעות מחברים זמינים. בהמשך מפורטים תרחישים אפשריים שבהם אפשר להשתמש ב-MirrorMaker 2.0:

  • העברת נתונים: העברת עומס העבודה של Kafka לאשכול חדש, כמו שמוסבר במדריך הזה.

  • תוכנית התאוששות מאסון (DR): יוצרים אשכול גיבוי כדי להבטיח את המשכיות העסקית במקרה של כשלים.

  • בידוד נתונים: שכפול סלקטיבי של נושאים לאשכול ציבורי תוך שמירה על אבטחת מידע אישי רגיש באשכול פרטי.

  • צבירת נתונים: איחוד נתונים מכמה אשכולות של Kafka לאשכול מרכזי למטרות ניתוח.

‫MirrorMaker 2.0 תומך ב-Kafka מגרסה 2.4.0 ואילך, ומציע את התכונות העיקריות הבאות:

  • שכפול מקיף: שכפול של כל הרכיבים הדרושים, כולל נושאים, נתונים והגדרות, קבוצות צרכנים עם היסטוריית מיקום ורשימות בקרת גישה (ACL).

  • שמירה על חלוקה למחיצות: שומרת על אותה תוכנית חלוקה למחיצות באשכול היעד, וכך מפשטת את המעבר לאפליקציות.

  • יצירה אוטומטית של נושאים ומחיצות: זיהוי ושכפול אוטומטיים של נושאים ומחיצות חדשים, כדי לצמצם את הצורך בהגדרה ידנית.

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

  • סובלנות תקלות ויכולת הרחבה: מאפשרת פעולה אמינה גם עם נפחי נתונים גדולים, ואפשר להרחיב אותה אופקית כדי לטפל בעומסי עבודה גדלים.

  • נושאים פנימיים לחוסן: נעשה שימוש בנושאים פנימיים לסנכרון של היסטים, לנקודות ביקורת ולפעימות לב. לנושאים האלה יש גורמי שכפול שניתנים להגדרה, כמו offset.syncs.topic.replication.factor, כדי להבטיח זמינות גבוהה ועמידות בפני תקלות.

ב-MirrorMaker 2.0 יש שני מצבי פריסה:

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

  • מצב אשכול Kafka Connect: ‏ MirrorMaker 2.0 פועל כמחברים באשכול Kafka Connect קיים.

תהליך עבודה כללי

בתרשים הבא מוצגת הארכיטקטורה למיגרציה של נתונים מאשכול Apache Kafka של מקור לאשכול של שירות מנוהל ל-Apache Kafka באמצעות MirrorMaker 2.0.

העברת נתוני Kafka באמצעות MirrorMaker 2.0.
איור 1. העברת נתונים מאשכול Apache Kafka של מקור לאשכול של שירות מנוהל ל-Apache Kafka באמצעות MirrorMaker 2.0.

כך הרכיבים פועלים יחד:

  • אשכול המקור: מייצג את אשכול Apache Kafka הקיים שלכם, שיכול להיות ממוקם בשרת מקומי או בסביבת ענן אחרת. הוא מכיל את הנושאים שרוצים להעביר. בדיאגרמה הזו, אשכול המקור Apache Kafka מכיל שלושה נושאים: Topic A,‏ B ו-C.

  • ‫MirrorMaker 2.0: הרכיב המרכזי הזה, שנפרס במכונה וירטואלית ב-Compute Engine כאשכול ייעודי של MirrorMaker 2.0, משכפל באופן פעיל נתונים מאשכול המקור של Apache Kafka לאשכול היעד של השירות המנוהל ל-Apache Kafka. חשוב לציין שהכלי גם יוצר באופן אוטומטי את הנושאים והמחיצות התואמים באשכול היעד אם הם לא קיימים, ומשקף את ההגדרה של אשכול המקור.

  • אשכול היעד: זהו האשכול שלכם בשירות המנוהל ל-Apache Kafka. הוא הופך למיקום החדש של נתוני Kafka, ו-MirrorMaker 2.0 מוודא שהנושאים והמחיצות נוצרים בהתאם לסביבת המקור.

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

  1. הערכה ראשונית

    • מתעדים את ההגדרה הקיימת של Kafka, כולל גודל האשכול, הנושאים, קצב העברת הנתונים וקבוצות הצרכנים.

    • תכננו את היעדים והאסטרטגיה של המיגרציה, כולל סובלנות לזמן השבתה וגישה למעבר חד למערכת אחרת (cutover).

    • הערכת המשאבים הנדרשים לאשכול שלכם בשירות המנוהל ל-Apache Kafka.

  2. הכנה

    • יוצרים אשכול של שירות מנוהל ל-Apache Kafka.

    • מגדירים קישוריות לרשת בין אשכול Kafka קיים לבין אשכול השירות המנוהל ל-Apache Kafka שנוצר זה עתה.

    • פורסים את MirrorMaker 2.0 ב Google Cloud מכונה וירטואלית.

  3. ביצוע ההעברה

    • מגדירים את MirrorMaker 2.0 לשכפול נתונים מאשכול Kafka קיים לאשכול שירות מנוהל ל-Apache Kafka.

    • עוקבים אחרי תהליך השכפול באמצעות מדדים של MirrorMaker 2.0.

    • מעבירים בהדרגה את הצרכנים והיצרנים לאשכול החדש של השירות המנוהל ל-Apache Kafka.

  4. אימות ומעבר חד למערכת אחרת (cutover)

    • אימות של תקינות הנתונים ותכונות האפליקציה באשכול של השירות המנוהל ל-Apache Kafka.

    • מבצעים את המעבר הסופי ומפנים את התנועה לאשכול של שירות מנוהל ל-Apache Kafka.

    • מוציאים משימוש את אשכול Kafka הישן.

  5. אחרי ההעברה

    • חשוב לעקוב באופן רציף אחרי הביצועים של אשכול שירות מנוהל ל-Apache Kafka.

    • בודקים ומעדכנים את התיעוד כך שישקף את השינויים.

צמצום זמן ההשבתה במהלך ההעברה

בקטע הזה מפורטים כמה שיקולים להעברת נתונים מ-Kafka בקוד פתוח אל השירות המנוהל ל-Apache Kafka באמצעות MirrorMaker 2.0. ‫MirrorMaker 2.0 מאפשר שכפול של נתונים והיסטים, כך שהצרכנים יכולים להמשיך מהנקודה הנכונה באשכול החדש. עם זאת, תכנון קפדני הוא חיוני כדי לצמצם את זמן ההשבתה במהלך תהליך ההעברה. כדאי לשקול את האסטרטגיות הבאות:

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

  • השקה בשלבים: מעבר בשלבים קטנים יותר ונוחים לניהול, החל מאפליקציות פחות קריטיות. הגישה הזו עוזרת לבודד בעיות פוטנציאליות ולמזער את ההשפעה של שיבושים.

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

  • דרישות לעיבוד הודעות: חשוב להבין את רמת הסבילות של האפליקציה להודעות כפולות או חסרות, ולהגדיר את הצרכנים בהתאם. ‫MirrorMaker 2.0 מציע הגדרות לטיפול בסמנטיקה של מסירת הודעות. לדוגמה, ב-sync.group.offsets.enabled יש תמיכה בסנכרון של היסט צרכנים. צרכנים יכולים להשתמש בהיסטים המסונכרנים כדי להמשיך לקרוא מהמקום שבו הם הפסיקו באשכול המקור. כך אפשר למנוע אובדן של הודעות או קבלה של יותר מדי כפילויות.

  • תקשורת ותיאום: תקשורת יעילה עם צוותי האפליקציות חיונית להעברה חלקה. צריך להגדיר ערוצי תקשורת ברורים ולתאם את מועדי המעבר.

התחברות ל- Google Cloudמ-Apache Kafka מקומי

אם אשכול Apache Kafka של המקור נמצא בשרת מקומי, תצטרכו ליצור חיבור מאובטח בין הרשת המקומית לבין הענן הווירטואלי הפרטי (VPC) שבו נמצא אשכול השירות המנוהל ל-Apache Kafka. בוחרים אחת מהאפשרויות הבאות מתוך Google Cloud.

  • ‫Cloud VPN: פתרון חסכוני שמתאים לצרכים של רוחב פס נמוך יותר או לניסויים ראשוניים בהעברה. הוא יוצר מנהרה מוצפנת באינטרנט הציבורי. מידע נוסף על Cloud VPN זמין בסקירה הכללית על Cloud VPN.

  • ‫Cloud Interconnect: מספק חיבור ייעודי עם רוחב פס גבוה בין הרשת המקומית שלכם לבין Google Cloud. האפשרות הזו מתאימה במיוחד לפריסות ברמת הארגון שדורשות תפוקה גבוהה יותר וחביון נמוך יותר. אתם יכולים לבחור בין Dedicated Interconnect (לחיבור פיזי ישיר) לבין Partner Interconnect (חיבור דרך ספק שירות נתמך). מידע נוסף על Google Cloud מאמרי העזרה בנושא Interconnect זמין בסקירה הכללית על Cloud Interconnect.

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

כדי להתחבר בצורה מאובטחת לאשכול שירות מנוהל ל-Apache Kafka מרשתות מקומיות או מרשתות VPC אחרות, אפשר להשתמש ב-Private Service Connect ‏ (PSC) דרך Cloud VPN או Cloud Interconnect. אין צורך להגדיר במפורש נקודות קצה (endpoints) של PSC. כשבוחרים תת-רשת במהלך יצירת אשכול, שירות מנוהל ל-Apache Kafka יוצר באופן אוטומטי את נקודות הקצה הנדרשות של PSC. התכונה הזו מפשטת את הגדרת הרשת, כי היא מאפשרת לכם לגשת לאשכול באמצעות כתובות IP פנימיות ב-VPC, בלי שתצטרכו לנהל כללי חומת אש מורכבים או כתובות IP ציבוריות.

מידע נוסף על הגדרת הרשת בשירות המנוהל ל-Apache Kafka זמין במאמר בנושא רשתות בשירות המנוהל ל-Apache Kafka.

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

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

  • מוודאים שגרסת Apache Kafka היא 2.4.0 ואילך.

    כדי לבדוק את הגרסה של אשכול Apache Kafka, עוברים לספריית ההתקנה של Kafka ומריצים את הפקודה bin/kafka-topics.sh --version

  • מזהים את האשכולות והנושאים שצריך להעביר.

  • לזהות את היצרנים והצרכנים שמשויכים לכל נושא.

  • זיהוי כל קבוצות הצרכנים.

  • קובעים את תפוקת ההודעות ברמת האשכול וברמת הנושא.

  • קובעים את גורם השכפול של האשכולות והנושאים.

  • תיעוד של הגדרות הצרכן, במיוחד פרוטוקולי אבטחה וכל שילוב עם שירותים אחרים. Google Cloud

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

חישוב גודל האשכול ביעד

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

‫Kafka בקוד פתוח מספק מדדי JMX. כדי לחשב בצורה מדויקת את גודל האשכול הנדרש בשירות המנוהל ל-Apache Kafka, אפשר להשתמש במדדי JMX הבאים. המדדים האלה מדווחים ברמת הברוקר. כדי לחשב את קצב העברת הנתונים של האשכול, צריך לצבור את הנתונים מכל הברוקרים.

  • ‫kafka.server:type=BrokerTopicMetrics,name=BytesInPerSec: המדד הזה מדווח על קצב הבייטים הנכנסים מלקוחות בכל הנושאים. כדי לקבל את שיעור ההסכמה המצטבר לכל הנושאים, משמיטים את הפרמטר topic={...}.

  • ‫kafka.server:type=BrokerTopicMetrics,name=BytesOutPerSec: המדד הזה מציג את קצב העברת הבייטים ללקוחות בכל הנושאים. כדי לקבל את השיעור הכולל, משמיטים את הפרמטר topic={...}.

אם תעקבו אחרי מדדי ה-JMX האלה לאורך זמן, תוכלו לאסוף נקודות נתונים כדי לחשב את המדדים הבאים:

  • Average Data In, MB/s: המדד הזה מייצג את הקצב הממוצע שבו הנתונים מוזנים לאשכול Kafka.

  • ‫Peak Data In, MB/s: המדד הזה מייצג את הקצב הכי גבוה שבו נתונים מוזנים לאשכול Kafka.

  • Average Data Out, MB/s: המדד הזה מייצג את הקצב הממוצע שבו הנתונים נצרכים מאשכול Kafka.

  • ‫Peak Data Out, MB/s: המדד הזה מייצג את הקצב הכי גבוה שבו מתבצע צריכת נתונים מאשכול Kafka.

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

Write-equivalent rate (Avg/Peak) = (total write bandwidth) + (total read bandwidth / 4)

השיעור הזה, ששווה לשיעור הכתיבה, עוזר לקבוע את עומס הכתיבה הכולל באשכול, שנדרש כדי להתאים את הגודל של האשכול בשירות המנוהל ל-Apache Kafka.

יצירת אשכול של שירות מנוהל ל-Apache Kafka

אשכול של שירות מנוהל ל-Apache Kafka ממוקם בGoogle Cloud פרויקט ובאזור ספציפיים. אפשר לגשת אליו באמצעות קבוצה של כתובות IP בתת-רשת אחת או יותר בכל ענן וירטואלי פרטי (VPC).

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

כדי לקבל את ההרשאות שנדרשות ליצירת אשכול, צריך לבקש מהאדמין להקצות לכם או לחשבון השירות שיוצר את האשכול את תפקיד ה-IAM ‏Managed Kafka Admin ‏(roles/managedkafka.admin) בפרויקט. מידע נוסף על הקצאת תפקידים מופיע במאמר ניהול הגישה לפרויקטים, לתיקיות ולארגונים.

כדי ליצור אשכול של שירות מנוהל ל-Apache Kafka, פועלים לפי ההוראות במדריך למתחילים בנושא יצירה וצריכה של הודעות באמצעות ה-CLI. יצירת אשכול אורכת בדרך כלל 20-30 דקות.

הגדרה של MirrorMaker 2.0 במצב אשכול עצמאי

במאגר הזה ב-GitHub יש מסמך הוכחת היתכנות וקוד לדוגמה שמראים איך להשתמש ב-MirrorMaker 2.0 וב-Terraform כדי להעביר נתונים מ-Kafka אל Google Cloud.

בקטע הזה מוסבר איך להתקין ולהגדיר את MirrorMaker 2.0 במצב אשכול עצמאי במכונה וירטואלית (VM) של Google Cloud . ההגדרה הזו מאפשרת לשכפל נתונים מאשכול Apache Kafka קיים לאשכול שירות מנוהל ל-Apache Kafka.

  1. יוצרים מכונה וירטואלית באותה רשת שקיבלה גישה לאשכול של השירות המנוהל ל-Apache Kafka. משתמשים בפקודה gcloud compute instances create.

    gcloud compute instances create VM_NAME\
 --zone=ZONE\
 [--image=IMAGE | --image-family=IMAGE_FAMILY]\
 --image-project=IMAGE_PROJECT\
 --machine-type=MACHINE_TYPE

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

    • ‫VM_NAME: השם של המכונה הווירטואלית שרוצים ליצור.
    • ‫ZONE: האזור שבו רוצים ליצור את המכונה הווירטואלית.
    • ‫IMAGE או IMAGE_FAMILY: האימג' או משפחת האימג' שרוצים להשתמש בהם עבור המכונה הווירטואלית.
    • ‫IMAGE_PROJECT: הפרויקט שבו נמצאת התמונה.
    • ‫MACHINE_TYPE: סוג המכונה שרוצים להשתמש בה למכונה הווירטואלית.

  2. כדי לגשת למכונה הווירטואלית החדשה שיצרתם, אתם יכולים להשתמש ב-SSH.

    מידע נוסף על חיבורי SSH זמין במאמר מידע על חיבורי SSH.

  3. כדי להוריד את Kafka ואז לחלץ אותו, מריצים את הפקודות הבאות בחלון המסוף של מכונת ה-VM החדשה:

    wget https://downloads.apache.org/kafka/3.7.1/kafka_2.13-3.7.1.tgz
tar -xzvf kafka_2.13-3.7.1.tgz

  4. מורידים את Java, מחלצים את החבילה ומגדירים את נתיב Java.

    # Download Java
wget https://download.java.net/java/GA/jdk11/9/GPL/openjdk-11.0.2_linux-x64_bin.tar.gz
# Extract Java
tar -xzvf openjdk-11.0.2_linux-x64_bin.tar.gz
# Set Java path
export PATH=$PATH:/java/jdk-11.0.2/bin/

  5. עורכים את הקובץ path/to/kafka/config/mm2.properties ומעדכנים את המאפיינים הבאים:

    clusters = source, target
source.bootstrap.servers = <source_kafka_bootstrap_servers>
target.bootstrap.servers = <target_kafka_bootstrap_servers>
source.security.protocol = SASL_SSL
source.sasl.mechanism = PLAIN
source.sasl.jaas.config = org.apache.kafka.common.security.plain.PlainLoginModule
required username="<source_kafka_username>" password="<source_kafka_password>";

target.security.protocol = SASL_SSL
target.sasl.mechanism = PLAIN
target.sasl.jaas.config = org.apache.kafka.common.security.plain.PlainLoginModule
required username="<target_kafka_username>" password="<target_kafka_password>";

mirrors = source->target
source->target.enabled=true

topics = .*
groups = .*

offset.syncs.topic.replication.factor = 3
checkpoints.topic.replication.factor = 3
heartbeats.topic.replication.factor = 3
emit.checkpoints.interval.seconds = 10

    • מחליפים את source_kafka_bootstrap_servers ואת target_kafka_bootstrap_servers בכתובות של שרת האתחול של אשכולות Kafka של המקור והיעד, בהתאמה. אפשר לקבל את כתובת שרת האתחול של השירות המנוהל ל-Apache Kafka באמצעות הפקודה managed-kafka clusters describe של Google Cloud CLI.

    • מחליפים את source_kafka_username ואת source_kafka_password בפרטי הכניסה של אשכול Kafka של המקור.

    • מחליפים את target_kafka_username ואת target_kafka_password בפרטי הכניסה של אשכול היעד של השירות המנוהל ל-Apache Kafka. הוראות להגדרת שם המשתמש והסיסמה מופיעות במאמר בנושא אימות SASL/PLAIN.

    • ההגדרות topics = .\* ו-groups = .\* משכפלות את כל הנושאים ואת קבוצות הצרכנים. אם צריך, אפשר לשנות את ההגדרות האלה כדי להגדיר אותן בצורה ספציפית יותר.

    • ההגדרה offset.syncs.topic.replication.factor = 3 קובעת את גורם השכפול לנושא הפנימי שמשמש את MirrorMaker 2.0 לסנכרון ההיסטים של הצרכנים בין אשכולות המקור והיעד. גורם השכפול 3 אומר שנתוני האופסט משוכפלים לשלושה ברוקרים באשכול היעד, וכך מובטחת זמינות גבוהה יותר ועמידות בפני תקלות.

    • ההגדרה checkpoints.topic.replication.factor = 3 קובעת את גורם השכפול לנושא פנימי אחר שמשמש את MirrorMaker 2.0 לאחסון נקודות ביקורת. נקודות ביקורת עוזרות ל-MirrorMaker 2.0 לעקוב אחרי ההתקדמות שלו ולחדש את השכפול מהנקודה הנכונה במקרה של כשלים או הפעלות מחדש.

    • ההגדרה heartbeats.topic.replication.factor = 3 קובעת את גורם השכפול לנושא הפנימי שמשמש את MirrorMaker 2.0 לשליחת פעימות לב. האותות של פעימות הלב מציינים שתהליך MirrorMaker 2.0 פעיל. גורם רפליקציה גבוה יותר מבטיח שהאותות האלה יישמרו בצורה מהימנה ושאפשר יהיה להשתמש בהם כדי לעקוב אחרי תקינות תהליך הרפליקציה.

    • ההגדרה emit.checkpoints.interval.seconds = 10 קובעת את התדירות שבה MirrorMaker 2.0 פולט נקודות ביקורת. במקרה הזה, נקודות הבדיקה מופקות כל 10 שניות. התדירות הזו מאפשרת איזון בין מעקב אחרי ההתקדמות לבין מזעור התקורה של כתיבת נקודות ביקורת.

  6. מפעילים את MirrorMaker 2.0. כדי להתחיל בתהליך, משתמשים בסקריפט connect-mirror-maker.sh.

    הסקריפט מפעיל את MirrorMaker 2.0 במצב עצמאי, והוא מתחיל לשכפל נתונים מאשכול Kafka של המקור לאשכול של השירות המנוהל ל-Apache Kafka.

שיקולים נוספים:

  • רשת: מוודאים שלמכונה הווירטואלית Google Cloud יש קישוריות לרשת, גם לאשכול Kafka של המקור וגם לאשכול של השירות המנוהל ל-Apache Kafka של היעד. אם אשכול המקור נמצא בשרת מקומי, יכול להיות שתצטרכו להגדיר VPN או Interconnect.

  • אבטחה: הגדירו פרוטוקולי אבטחה מתאימים וכללים לחומת אש כדי לאבטח את מופע MirrorMaker 2.0 ואת אשכולות Kafka.

אם תפעלו לפי השלבים האלה, תוכלו להתקין ולהגדיר את MirrorMaker 2.0 במצב של אשכול עצמאי במכונה וירטואלית Google Cloud כדי להעביר את נתוני Kafka לשירות המנוהל ל-Apache Kafka.

מעקב

עוקבים אחרי התהליך של MirrorMaker 2.0 כדי לוודא שהוא פועל בצורה תקינה ומשכפל את הנתונים כצפוי. אתם יכולים להשתמש במדדים המובנים של MirrorMaker 2 או בכלים אחרים לניטור. אחרי העברת האפליקציות, כדאי לעקוב אחרי הדברים הבאים כדי לוודא שההעברה הצליחה:

  • קצב העברת הנתונים במורד הזרם: מוודאים שלא חלו שינויים משמעותיים בקצב העברת הנתונים במורד הזרם. לדוגמה, אם אתם משתמשים ב-Dataflow במורד הזרם, קצב העברת הנתונים והמדדים שקשורים ל-Kafka צריכים להישאר עקביים.

  • ניצול המעבד והזיכרון: אפשר לעקוב אחרי ניצול המעבד והזיכרון באשכול של השירות המנוהל ל-Apache Kafka באמצעות Cloud Monitoring. כדי להבטיח ביצועים אופטימליים, רצוי ששיעור הניצול יישאר מתחת ל-75%.

  • יומני שגיאות: מומלץ לבדוק באופן קבוע את Cloud Logging כדי לראות אם יש יומני שגיאות שקשורים לאשכול של השירות המנוהל ל-Apache Kafka או לאפליקציות שלכם. חשוב לטפל בשגיאות בהקדם האפשרי כדי למנוע שיבושים.

מגבלות

  • כדי להשתמש ב-MirrorMaker 2.0, אשכול Apache Kafka של המקור צריך להיות בגרסה 2.4.0 ומעלה.