העברה מ-HDFS ל-Cloud Storage

‫Storage Transfer Service תומך בהעברות ממקורות של מערכת קבצים מבוזרת (HDFS) של Hadoop בענן ובארגון.

העברות מ-HDFS חייבות להשתמש ב-Cloud Storage כיעד.

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

הגדרת ההרשאות

לפני שיוצרים העברה, צריך להגדיר הרשאות לישויות הבאות:

חשבון המשתמש שמשמש ליצירת ההעברה. זהו החשבון שמחוברים אליו במסוף Google Cloud או החשבון שמצוין כשמתבצע אימות ל-CLI של gcloud. חשבון המשתמש יכול להיות חשבון משתמש רגיל או חשבון שירות שמנוהל על ידי משתמש.
חשבון השירות בניהול Google, שנקרא גם סוכן השירות, שמשמש את Storage Transfer Service. בדרך כלל, החשבון הזה מזוהה באמצעות כתובת האימייל שלו, בפורמט project-PROJECT_NUMBER@storage-transfer-service.iam.gserviceaccount.com.
חשבון סוכן ההעברה שמספק הרשאות Google Cloud לסוכני העברה. חשבונות של סוכני העברה משתמשים בפרטי הכניסה של המשתמש שמתקין אותם, או בפרטי הכניסה של חשבון שירות שמנוהל על ידי משתמש, כדי לבצע אימות.

הוראות מפורטות זמינות במאמר בנושא הרשאות להעברה מבוססת-סוכן.

התקנת סוכנים במאגר סוכנים

העברות שמבוססות על סוכנים משתמשות בסוכני תוכנה כדי לתזמן העברות. צריך להתקין את הסוכנים האלה במכונה אחת או יותר עם גישה למערכת הקבצים. לסוכנים צריכה להיות גישה ל-namenode, לכל datanode, ל-Hadoop Key Management Server‏ (KMS) ול-Kerberos Key Distribution Center‏ (KDC).

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

  • כדאי להוסיף עוד סוכנים, עד למחצית ממספר הצמתים באשכול HDFS. לדוגמה, באשכול עם 30 צמתים, הגדלה של מספר הסוכנים מ-5 ל-15 אמורה לשפר את הביצועים, אבל מעבר ל-15 סוכנים לא צפוי להניב שיפור משמעותי.

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

  • לסוכנים נוספים יש בדרך כלל השפעה גדולה יותר על הביצועים כשמבצעים העברה שכוללת מספר גדול של קבצים קטנים. כדי להשיג תפוקה גבוהה, Storage Transfer Service מבצע משימות העברה במקביל בין כמה סוכנים. ככל שיש יותר קבצים בעומס העבודה, כך יש יותר תועלת בהוספת סוכנים.

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

יצירת מאגר סוכנים

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

התקנת סוכנים

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

מסוף Google Cloud

  1. נכנסים לדף Agent pools במסוף Google Cloud .

    כניסה לדף Agent pools

  2. בוחרים את מאגר הסוכנים שאליו רוצים להוסיף את הסוכן החדש.

  3. לוחצים על התקנת נציג.

  4. פועלים לפי ההוראות כדי להתקין ולהפעיל את הסוכן.

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

‫CLI של gcloud

כדי להתקין סוכן אחד או יותר באמצעות ה-CLI של gcloud, מריצים את הפקודה gcloud transfer agents install:

gcloud transfer agents install --pool=POOL_NAME \
  --count=NUM_AGENTS \
  --mount-directories=MOUNT_DIRECTORIES \
  --hdfs-namenode-uri=HDFS_NAMENODE_URI \
  --hdfs-username=HDFS_USERNAME \
  --hdfs-data-transfer-protection=HDFS_DATA_TRANSFER_PROTECTION \
  --kerberos-config-file=KERBEROS_CONFIG_FILE \
  --kerberos-keytab-file=KERBEROS_KEYTAB_FILE \
  --kerberos-user-principal=KERBEROS_USER_PRINCIPAL \
  --kerberos-service-principal=KERBEROS_SERVICE_PRINCIPAL \

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

  • ‫--hdfs-namenode-uri מציין אשכול HDFS כולל סכימה, namenode ויציאה, בפורמט URI. לדוגמה:

    • rpc://my-namenode:8020
    • http://my-namenode:9870

    משתמשים ב-HTTP או ב-HTTPS עבור WebHDFS. אם לא מסופק סכימה, ההנחה היא שמדובר ב-RPC. אם לא מציינים יציאה, ברירת המחדל היא 8020 ל-RPC,‏ 9870 ל-HTTP ו-9871 ל-HTTPS. לדוגמה, הקלט my-namenode הופך ל-rpc://my-namenode:8020.

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

  • ‫--hdfs-username הוא שם המשתמש לחיבור לאשכול HDFS עם אימות פשוט. אל תכללו את הדגל הזה אם אתם מבצעים אימות באמצעות Kerberos, או אם אתם מתחברים ללא אימות.

  • ‫--hdfs-data-transfer-protection (אופציונלי) היא הגדרת איכות ההגנה (QOP) בצד הלקוח עבור אשכולות עם Kerberos. הערך לא יכול להיות מגביל יותר מהערך של QOP בצד השרת. הערכים התקפים הם: authentication,‏ integrity ו-privacy.

אם אתם מבצעים אימות באמצעות Kerberos, צריך לכלול גם את הדגלים הבאים:

  • ‫--kerberos-config-file הוא הנתיב לקובץ התצורה של Kerberos. לדוגמה, --kerberos-config-file=/etc/krb5.conf.

  • ‫--kerberos-user-principal הוא שם המשתמש הראשי ב-Kerberos שבו רוצים להשתמש. לדוגמה, --kerberos-user-principal=user1.

  • ‫--kerberos-keytab-file הוא הנתיב לקובץ Keytab שמכיל את שם המשתמש שצוין באמצעות הדגל --kerberos-user-principal. לדוגמה, --kerberos-keytab-file=/home/me/kerberos/user1.keytab.

  • ‫--kerberos-service-principal הוא השם הראשי של השירות ב-Kerberos שבו רוצים להשתמש, בפורמט <primary>/<instance>. התחום ממופה מקובץ התצורה של Kerberos. המערכת מתעלמת מכל תחום שסופק. אם לא מציינים את הדגל הזה, ברירת המחדל היא hdfs/<namenode_fqdn>, כאשר <namenode_fqdn> הוא שם דומיין שמוגדר במלואו שצוין בקובץ תצורה.

    לדוגמה, --kerberos-service-principal=hdfs/my-namenode.a.example.com.

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

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

docker run

לפני שמשתמשים ב-docker run כדי להתקין סוכנים, צריך לפעול לפי ההוראות להתקנת Docker.

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

הדגלים הנדרשים של הפקודה תלויים בסוג האימות שבו אתם משתמשים.

Kerberos

כדי לבצע אימות למערכת הקבצים באמצעות Kerberos, משתמשים בפקודה הבאה:

sudo docker run -d --ulimit memlock=64000000 --rm \
  --network=host \
  -v /:/transfer_root \
  gcr.io/cloud-ingest/tsop-agent:latest \
  --enable-mount-directory \
  --project-id=${PROJECT_ID} \
  --hostname=$(hostname) \
  --creds-file="service_account.json" \
  --agent-pool=${AGENT_POOL_NAME} \
  --hdfs-namenode-uri=cluster-namenode \
  --kerberos-config-file=/etc/krb5.conf \
  --kerberos-user-principal=user \
  --kerberos-keytab-file=/path/to/folder.keytab

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

  • אם מריצים יותר מסוכן אחד במחשב, צריך להשמיט את --network=host.

  • ‫--hdfs-namenode-uri: סכימה, שם צומת ויציאה, בפורמט URI, שמייצגים אשכול HDFS. לדוגמה:

    • rpc://my-namenode:8020
    • http://my-namenode:9870

משתמשים ב-HTTP או ב-HTTPS עבור WebHDFS. אם לא מסופק סכימה, ההנחה היא שמדובר ב-RPC. אם לא מציינים יציאה, ברירת המחדל היא 8020 ל-RPC,‏ 9870 ל-HTTP ו-9871 ל-HTTPS. לדוגמה, הקלט my-namenode הופך ל-rpc://my-namenode:8020.

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

  • ‫--kerberos-config-file: הנתיב לקובץ התצורה של Kerberos. ערך ברירת המחדל הוא /etc/krb5.conf.
  • ‫--kerberos-user-principal: חשבון המשתמש ב-Kerberos.
  • ‫--kerberos-keytab-file: הנתיב לקובץ Keytab שמכיל את שם המשתמש (principal) שצוין באמצעות --kerberos-user-principal.
  • ‫--kerberos-service-principal: השם הראשי של השירות ב-Kerberos לשימוש, בפורמט service/instance. התחום ממופה מקובץ ההגדרות של Kerberos. כל תחום שסופק מתעלמים ממנו. אם לא מציינים את הדגל הזה, ברירת המחדל היא hdfs/<namenode_fqdn>, כאשר fqdn הוא שם הדומיין המלא.

אימות פשוט

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

sudo docker run -d --ulimit memlock=64000000 --rm \
  --network=host \
  -v /:/transfer_root \
  gcr.io/cloud-ingest/tsop-agent:latest \
  --enable-mount-directory \
  --project-id=${PROJECT_ID} \
  --hostname=$(hostname) \
  --creds-file="${CREDS_FILE}" \
  --agent-pool="${AGENT_POOL_NAME}" \
  --hdfs-namenode-uri=cluster-namenode \
  --hdfs-username="${USERNAME}"

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

  • ‫--hdfs-username: שם המשתמש שמשמש להתחברות לאשכול HDFS באמצעות אימות פשוט.
  • ‫--hdfs-namenode-uri: סכימה, שם צומת ויציאה, בפורמט URI, שמייצגים אשכול HDFS. לדוגמה:
    • rpc://my-namenode:8020
    • http://my-namenode:9870

משתמשים ב-HTTP או ב-HTTPS עבור WebHDFS. אם לא מסופק סכימה, ההנחה היא שמדובר ב-RPC. אם לא מציינים יציאה, ברירת המחדל היא 8020 ל-RPC,‏ 9870 ל-HTTP ו-9871 ל-HTTPS. לדוגמה, הקלט my-namenode הופך ל-rpc://my-namenode:8020.

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

ללא אימות

כדי להתחבר למערכת הקבצים ללא אימות:

sudo docker run -d --ulimit memlock=64000000 --rm \
  --network=host \
  -v /:/transfer_root \
  gcr.io/cloud-ingest/tsop-agent:latest \
  --enable-mount-directory \
  --project-id=${PROJECT_ID} \
  --hostname=$(hostname) \
  --creds-file="${CREDS_FILE}" \
  --agent-pool="${AGENT_POOL_NAME}" \
  --hdfs-namenode-uri=cluster-namenode \

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

  • ‫--hdfs-namenode-uri: סכימה, namenode ויציאה, בפורמט URI, שמייצגים אשכול HDFS. לדוגמה:
    • rpc://my-namenode:8020
    • http://my-namenode:9870

משתמשים ב-HTTP או ב-HTTPS עבור WebHDFS. אם לא מסופק סכימה, ההנחה היא שמדובר ב-RPC. אם לא מציינים יציאה, ברירת המחדל היא 8020 ל-RPC,‏ 9870 ל-HTTP ו-9871 ל-HTTPS. לדוגמה, הקלט my-namenode הופך ל-rpc://my-namenode:8020.

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

אפשרויות העברה

התכונות הבאות של Storage Transfer Service זמינות להעברות מ-HDFS ל-Cloud Storage.

בקובצים שמועברים מ-HDFS לא נשמרים המטא-נתונים שלהם.

יצירת העברה

אל תכללו בשם של עבודת ההעברה מידע רגיש כמו פרטים אישיים מזהים (PII) או נתוני אבטחה. יכול להיות ששמות המשאבים יועברו לשמות של משאבים אחרים ב-Google Cloud, ויוצגו למערכות פנימיות של Google מחוץ לפרויקט שלכם.

שירות העברת הנתונים (Storage Transfer Service) מספק כמה ממשקים שדרכם אפשר ליצור העברה.

מסוף Google Cloud

  1. נכנסים לדף Storage Transfer Service במסוף Google Cloud .

    מעבר אל Storage Transfer Service

  2. לוחצים על Transfer. מוצג הדף Create a transfer job.

  3. בוחרים באפשרות מערכת קבצים מבוזרת של Hadoop בתור סוג המקור. יעד ההעברה חייב להיות Google Cloud Storage.

    לוחצים על השלב הבא.

הגדרת המקור

  1. מציינים את המידע הנדרש להעברה הזו:

    1. בוחרים את מאגר הסוכנים שהגדרתם להעברה הזו.

    2. מזינים את הנתיב להעברה, ביחס לספריית הבסיס.

  2. אפשר גם לציין מסננים להחלה על נתוני המקור.

  3. לוחצים על השלב הבא.

הגדרת היעד

  1. בשדה Bucket or folder, מזינים את קטגוריית היעד ואת שם התיקייה (אופציונלי), או לוחצים על Browse כדי לבחור קטגוריה מתוך רשימת הקטגוריות הקיימות בפרויקט הנוכחי. כדי ליצור מאגר חדש, לוחצים על סמל של דלי יצירת מאגר חדש.

  2. לוחצים על השלב הבא.

תזמון ההעברה

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

לוחצים על השלב הבא.

בחירת הגדרות ההעברה

  1. בשדה Description (תיאור), מזינים תיאור של ההעברה. מומלץ להזין תיאור בעל משמעות וייחודי כדי שתוכלו להבחין בין המשרות.

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

  3. בקטע When to overwrite (מתי להחליף), בוחרים באחת מהאפשרויות הבאות:

    • אף פעם: לא יתבצעו החלפות של קבצים ביעד. אם קיים קובץ עם אותו שם, הוא לא יועבר.

    • אם שונה: מחליף את קובצי היעד אם לקובץ המקור עם אותו שם יש ערכי Etags או סיכום ביקורת שונים.

    • תמיד: תמיד מחליף את קובצי היעד כששם קובץ המקור זהה, גם אם הם זהים.

  4. בקטע When to delete (מתי למחוק), בוחרים באחת מהאפשרויות הבאות:

    • אף פעם: הקבצים לא יימחקו מהמקור או מהיעד.

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

      האפשרות הזו מבטיחה שקטגוריית היעד של Cloud Storage תהיה זהה למקור.

  5. בוחרים אם להפעיל רישום ביומן של העברות ו/או התראות Pub/Sub.

לוחצים על Create (יצירה) כדי ליצור את עבודת ההעברה.

‫CLI של gcloud

כדי ליצור משימת העברה חדשה, משתמשים בפקודה gcloud transfer jobs create. יצירת משימה חדשה מתחילה את ההעברה שצוינה, אלא אם צוין לוח זמנים או --do-not-run.

gcloud transfer jobs create \
  hdfs:///PATH/ gs://BUCKET_NAME/PATH/
  --source-agent-pool=AGENT_POOL_NAME

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

  • ‫PATH הוא נתיב מוחלט מהבסיס של אשכול HDFS. השם של צומת השמות והיציאה של האשכול מוגדרים ברמת הסוכן, ולכן בפקודה ליצירת העבודה צריך לציין רק את הנתיב (אופציונלי) ואת מאגר הסוכנים.

  • ‫--source-agent-pool מציין את מאגר הסוכנים של המקור שבו יש להשתמש להעברה הזו.

אפשרויות נוספות:

  • האפשרות --do-not-run מונעת מ-Storage Transfer Service להריץ את העבודה אחרי שליחת הפקודה. כדי להריץ את העבודה, צריך לעדכן אותה כדי להוסיף לוח זמנים, או להשתמש בפקודה jobs run כדי להתחיל אותה באופן ידני.

  • ‫--manifest-file מציין את הנתיב לקובץ CSV ב-Cloud Storage שמכיל רשימה של קבצים להעברה מהמקור. למידע על הפורמט של קובץ המניפסט, אפשר לעיין במאמר העברה של קבצים או אובייקטים ספציפיים באמצעות מניפסט.

  • פרטי המשימה: אפשר לציין --name ו--description.

  • לוח זמנים: מציינים --schedule-starts,‏ --schedule-repeats-every ו---schedule-repeats-until, או --do-not-run.

  • תנאים לאובייקטים: משתמשים בתנאים כדי לקבוע אילו אובייקטים יועברו. הם כוללים את --include-prefixes ואת --exclude-prefixes, ואת התנאים מבוססי-הזמן ב---include-modified-[before | after]-[absolute | relative]. אם ציינתם תיקייה עם המקור, מסנני הקידומת הם יחסיים לתיקייה הזו. מידע נוסף זמין במאמר בנושא סינון אובייקטים של מקור לפי קידומת.

  • אפשרויות העברה: מציינים אם להחליף קבצים ביעד (--overwrite-when=different או always) ואם למחוק קבצים מסוימים במהלך ההעברה או אחריה (--delete-from=destination-if-unique או source-after-transfer). אפשר גם להגדיר מחלקת אחסון לאובייקטים שהועברו (--custom-storage-class).

  • התראות: הגדרה של התראות Pub/Sub להעברות באמצעות --notification-pubsub-topic,‏ --notification-event-types ו---notification-payload-format.

כדי לראות את כל האפשרויות, מריצים את הפקודה gcloud transfer jobs create --help או מעיינים במאמרי העזרה בנושא gcloud.

API ל-REST

כדי ליצור העברה ממקור HDFS באמצעות API בארכיטקטורת REST, יוצרים אובייקט JSON שדומה לדוגמה הבאה.

POST https://storagetransfer.googleapis.com/v1/transferJobs
{
  ...
  "transferSpec": {
    "source_agent_pool_name":"POOL_NAME",
    "hdfsDataSource": {
      "path": "/mount"
    },
    "gcsDataSink": {
      "bucketName": "SINK_NAME"
    },
    "transferOptions": {
      "deleteObjectsFromSourceAfterTransfer": false
    }
  }
}

פרטים על שדות נתמכים נוספים מופיעים במפרט של transferJobs.create.

אשכולות עם כמה namenodes

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

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

אפשר לאחזר את הצומת הפעיל של שמות באשכול על ידי הרצת הפקודה:

hdfs haadmin -getAllServiceState