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

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

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

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

דרישות מוקדמות

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

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

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

בהעברות מבוססות-סוכנים, סוכני תוכנה מתזמרים את ההעברות. צריך להתקין את הסוכנים האלה במכונה אחת או יותר עם גישה למערכת הקבצים. לסוכנים צריכה להיות גישה ל-namenode, לכל ה-datanodes, לשרת ניהול המפתחות (KMS) של Hadoop ולמרכז להקצאת מפתחות (KDC) של Kerberos.

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

• הוספת סוכנים יכולה לעזור, עד כמחצית ממספר הצמתים באשכול ה-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.

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

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

• ‫--hdfs-data-transfer-protection (אופציונלי) היא הגדרת איכות ההגנה (QOP) בצד הלקוח לאשכולות Kerberized. הערך לא יכול להיות מחמיר יותר מהערך של 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.

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

הדגל --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.

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

• ‫--kerberos-config-file: הנתיב לקובץ התצורה של Kerberos. ערך ברירת המחדל הוא /etc/krb5.conf.
• ‫--kerberos-user-principal: חשבון המשתמש של Kerberos.
• ‫--kerberos-keytab-file: הנתיב לקובץ Keytab שמכיל את חשבון המשתמש שצוין באמצעות --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.

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

אין אימות

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

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: סכימה, צומת שם ויציאה, בפורמט 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.

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

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

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

• סינון לפי קידומת
• מחיקה במקור
• מניפסט
• Cloud Monitoring

קבצים שמועברים מ-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 Distributed File System בתור Source type. היעד חייב להיות Google Cloud Storage.

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

הגדרת המקור

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

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

   2. מזינים את הנתיב שממנו רוצים להעביר, ביחס לתיקיית השורש.

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

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

הגדרת הכיור

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

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

תזמון ההעברה

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

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

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

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

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

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

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

   • אם שונה: החלפת קובצי היעד אם לקובץ המקור עם אותו שם יש ערכי Etag או סיכום ביקורת (checksum) שונים.

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

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

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

   • Delete files from destination if they're not also at source: אם הקבצים בקטגוריית היעד של Cloud Storage לא נמצאים גם במקור, הקבצים נמחקים מקטגוריית Cloud Storage.

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

5. בוחרים אם להפעיל את האפשרות transfer logging או את האפשרות Pub/Sub notifications, או את שתיהן.

לוחצים על 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. ה-namenode והיציאה של האשכול מוגדרים ברמת הסוכן, כך שבפקודה ליצירת המשימה צריך לציין רק את הנתיב (אופציונלי) ואת מאגר הסוכנים.

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

האפשרויות הנוספות כוללות:

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

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

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

• ‫Schedule: מציינים את הערכים --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 מוגדר עם כמה צומתי שם ("זמינות גבוהה"), ויש אירוע של יתירות כשל שגורם לצומת שם ראשי חדש, צריך להתקין מחדש את הסוכנים עם צומת השם הנכון.

כדי למחוק את הנציגים הישנים, קראו את המאמר מחיקת נציג.

כדי לאחזר את ה-namenode הפעיל של האשכול, מריצים את הפקודה:

hdfs haadmin -getAllServiceState