ניהול סוכני העברה

סוכני Storage Transfer Service הם אפליקציות שפועלות בתוך קונטיינר Open Container Initiative‏ (OCI), ומתואמות עם Storage Transfer Service להעברות שכוללות מערכות קבצים או אחסון שתואם ל-S3.

כברירת מחדל, Storage Transfer Service משתמש ב-Docker כדי ליצור ולהריץ קונטיינרים של OCI. Storage Transfer Service תומך גם ב-Podman לניהול קונטיינרים. כדי להשתמש ב-Podman, צריך להתקין את הסוכנים באמצעות הפקודה podman run.

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

לא נדרשים סוכנים להעברות מ-Amazon S3. אחסון שתואם ל-S3 מתייחס למערכות אחסון שמשתמשות ב-S3 API אבל לא מתארחות ישירות ב-Amazon.

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

סקירה כללית

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

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

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

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

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

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

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

אם אתם מתכוונים להשתמש בפקודות gcloud, תצטרכו להתקין את ה-CLI של gcloud.

התקנה והפעלה של סוכני העברה

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

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

אסור לכלול בקידומת של מזהה הסוכן מידע רגיש כמו פרטים אישיים מזהים (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

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

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

מקורות שתואמים ל-S3

כשמתקינים סוכנים לשימוש עם מקור שתואם ל-S3, צריך לספק פרטי כניסה ל-AWS כמשתני סביבה עם הערכים AWS_ACCESS_KEY_ID ו-AWS_SECRET_ACCESS_KEY, או כפרטי כניסה שמוגדרים כברירת מחדל בקובצי התצורה של המערכת.

export AWS_ACCESS_KEY_ID=ID
export AWS_SECRET_ACCESS_KEY=SECRET
gcloud transfer agents install --pool=POOL_NAME \
  --creds-file=/relative/path/to/service-account-key.json

שימוש במפתח של חשבון שירות

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

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

כדי להריץ סוכנים באמצעות מפתח של חשבון שירות, משתמשים באפשרות --creds-file:

gcloud transfer agents install --pool=POOL_NAME --count=NUM_AGENTS \
   --creds-file=/relative/path/to/service-account-key.json

מידע נוסף

כדי לראות את הרשימה המלאה של הדגלים האופציונליים, מריצים את הפקודה gcloud transfer agents install --help או קוראים את המאמר בנושא gcloud transfer.

Docker

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

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

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

פרטי כניסה שמוגדרים כברירת מחדל

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

sudo docker run -ti --name gcloud-config google/cloud-sdk gcloud auth application-default login

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

sudo docker run --ulimit memlock=64000000 -d --rm \
--volumes-from gcloud-config \
-v HOST_DIRECTORY:CONTAINER_DIRECTORY \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT_ID \
--hostname=$(hostname) \
--agent-pool=POOL_NAME

אימות באמצעות חשבון שירות

כדי להתקין ולהריץ סוכני העברה docker run באמצעות פרטי כניסה של חשבון שירות, מציינים את הנתיב למפתח של חשבון השירות בפורמט JSON באמצעות הדגל --creds-file.

הנתיב חייב להתחיל במחרוזת /transfer_root.

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

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

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

sudo docker run --ulimit memlock=64000000 -d --rm \
-v HOST_DIRECTORY:CONTAINER_DIRECTORY \
-v PATH/TO/KEY.JSON:/etc/gcloud/key.json:ro \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT_ID \
--creds-file=/etc/gcloud/key.json \
--hostname=$(hostname) \
--agent-pool=POOL_NAME

אפשרויות ודגלים

מחליפים את המשתנים בדוגמאות שלמעלה במידע הבא:

• ‫HOST_DIRECTORY היא הספרייה במחשב המארח שממנה רוצים להעתיק. אפשר להשתמש ביותר מדגל -v כדי לציין ספריות נוספות להעתקה.
• ‫CONTAINER_DIRECTORY היא הספרייה שממופה בתוך מאגר הסוכנים. הערך חייב להיות זהה לערך של HOST_DIRECTORY.
• ‫PROJECT_ID הוא מזהה הפרויקט שבו מתבצעת ההעברה.
• ‫POOL_NAME הוא שם מאגר הסוכנים שבו רוצים להתקין את הסוכן הזה. אם לא מציינים את הדגל הזה, הסוכן מותקן במאגר transfer_service_default של הפרויקט.

הפקודה docker run תומכת בדגלים נוספים.

• ‫--enable-mount-directory טוען את כל מערכת הקבצים בספרייה /transfer_root במאגר התגים. אם מציינים את --enable-mount-directory, המערכת לא מחילה הגבלות על ספריות באמצעות הדגל -v.

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

• ‫--creds-file=/etc/gcloud/key.json מציין את הנתיב לקובץ פרטי הכניסה של חשבון השירות בפורמט JSON במאגר. הקובץ הזה מותקן באמצעות הדגל -v <var>HOST_PATH/TO/KEY.JSON</var>:/etc/gcloud/key.json:ro בפקודה.

• הערך --enable-s3 מציין שהסוכן הזה מיועד להעברות מאחסון שתואם ל-S3. אי אפשר להשתמש בסוכנים שהותקנו באמצעות האפשרות הזו להעברות ממערכות קבצים של POSIX.

  אם ההעברה היא מ-AWS S3 או מאחסון שתואם ל-S3, צריך להעביר את מזהה מפתח הגישה ואת המפתח הסודי באמצעות משתני סביבה:

  sudo docker run --ulimit memlock=64000000 -d --rm \
  -v HOST_DIRECTORY:CONTAINER_DIRECTORY \
  -v PATH/TO/KEY.JSON:/etc/gcloud/key.json:ro \
  -e AWS_ACCESS_KEY_ID=AWS_ACCESS_KEY_ID \
  -e AWS_SECRET_ACCESS_KEY=AWS_SECRET_ACCESS_KEY \
  gcr.io/cloud-ingest/tsop-agent:latest \
  --project-id=PROJECT_ID \
  --creds-file=/etc/gcloud/key.json \
  --hostname=$(hostname) \
  --agent-pool=POOL_NAME
  

• ‫--gcs-api-endpoint=storage.LOCATION.rep.googleapis.com מציין נקודת קצה אזורית של Cloud Storage. כשמציינים נקודת קצה אזורית של Cloud Storage, כל תעבורת העברת הנתונים דרך הסוכן נשארת באותו אזור של Google Cloud. פרטים נוספים זמינים במאמר בנושא נקודות קצה אזוריות.

• ‫--env HTTPS_PROXY=PROXY מגדיר שרת proxy קדימה ברשת. הערך של PROXY הוא כתובת ה-URL של HTTP והיציאה של שרת ה-proxy. כדי למנוע כפילות של בקשות בהצפנת TLS, חשוב לציין כתובת URL מסוג HTTP ולא כתובת URL מסוג HTTPS. בקשות שעברו עטיפה כפולה מונעות משרת ה-proxy לשלוח בקשות יוצאות תקינות.

• ‫--agent-id-prefix=ID_PREFIX מציין קידומת אופציונלית שמופיעה לפני מזהה הסוכן כדי לעזור לזהות את הסוכן או את המחשב שלו במסוף Google Cloud . כשמשתמשים בתחילית, מזהה הסוכן מעוצב כך: prefix + hostname + Docker container ID.

• ‫--log-dir=LOGS_DIRECTORY משנה את הספרייה שאליה הסוכן כותב יומנים. ספריית ברירת המחדל היא /tmp/.

  אם לא ציינתם את --enable_mount_directory, אתם צריכים להוסיף את הקידומת /transfer_root לנתיב הזה. לדוגמה: /transfer_root/logs.

• ‫--max-physical-mem=MAX_MEMORY: ברירת המחדל של הסוכנים היא שימוש במאגר של 8GB. אם ברירת המחדל לא מתאימה לסביבה שלכם, אתם יכולים לציין את השימוש המקסימלי הרלוונטי בזיכרון בפורמטים הבאים:

  ערך של max-physical-mem	הגדרת זיכרון מקסימלית
  6g	‫6 ג'יגה-בייט
  6gb	‫6 ג'יגה-בייט
  6GiB	‫6 ג'יביבייט

  הערה: הדגל הזה לא מגביל את הזיכרון הכולל של מאגר התגים. כדי למנוע שגיאות OOM, צריך להגדיר את הערך הזה ל-50-60%
  מזיכרון ה-RAM הכולל של המאגר.

• ‫--network=DOCKER_NETWORK: ציון רשת Docker לקונטיינר הזה. ציון --network=host יכול לשפר את הביצועים על ידי הפחתת התקורה ברשת, אבל מאפשר גישה מלאה של מאגר התגים לרשת של המארח.

• ‫--kerberos-disable-pa-fx-fast מונעת מסוכנים להשתמש במשא ומתן מהיר עם Kerberos להעברות HDFS. משתמשים בדגל הזה אם המרכז להקצאת מפתחות (KDC) של Kerberos לא תומך בניהול משא ומתן של FAST.

Podman

לפני שמשתמשים ב-Podman כדי להתקין סוכנים, צריך להתקין את Podman:

sudo apt-get update
sudo apt-get -y install podman

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

פרטי כניסה שמוגדרים כברירת מחדל

כדי לאפשר לקונטיינר של הסוכן לבצע אימות באמצעות פרטי ברירת המחדל של Google Cloud CLI, יוצרים נפח שמכיל קובץ עם פרטי ברירת המחדל של האפליקציה באמצעות הרצת הפקודה הבאה:

gcloud auth print-access-token | podman login -u oauth2accesstoken --password-stdin gcr.io
sudo podman pull gcr.io/google.com/cloudsdktool/google-cloud-cli:stable
sudo podman run -ti --replace --name gcloud-config gcr.io/google.com/cloudsdktool/google-cloud-cli:stable gcloud auth application-default login

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

sudo podman run --ulimit memlock=64000000 -d --rm \
--volumes-from gcloud-config \
-v HOST_DIRECTORY:CONTAINER_DIRECTORY \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT_ID \
--hostname=$(hostname) \
--agent-pool=POOL_NAME

אימות באמצעות חשבון שירות

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

1. מציבים את מיקום המארח של המפתח בכל נתיב בכלי הקיבול. לדוגמה: -v $HOME/.config/gcloud/credentials.json:/key.json:ro. הפקודה הזו מציינת שהמפתח נמצא במחשב המארח בנתיב $HOME/.config/gcloud/credentials.json וצריך לטעון אותו כ-/key.json במאגר. הסימן ro מציין שהקובץ זמין לקריאה בלבד עבור המאגר.
2. מציינים את נתיב מאגר התגים של המפתח כערך של --creds-file. בדוגמה מהשלב הקודם, מציינים את הערך --creds-file=/key.json.

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

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

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

sudo podman run --ulimit memlock=64000000 -d --rm \
-v HOST_DIRECTORY:CONTAINER_DIRECTORY \
-v HOST_PATH/TO/KEY.JSON:/etc/gcloud/key.json:ro \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT_ID \
--creds-file=/etc/gcloud/key.json \
--hostname=$(hostname) \
--agent-pool=POOL_NAME

אפשרויות ודגלים

מחליפים את המשתנים בדוגמאות שלמעלה במידע הבא:

• ‫HOST_DIRECTORY היא הספרייה במחשב המארח שממנה רוצים להעתיק. אפשר להשתמש ביותר מדגל -v כדי לציין ספריות נוספות להעתקה.
• ‫CONTAINER_DIRECTORY היא הספרייה שממופה בתוך מאגר הסוכנים. הערך חייב להיות זהה לערך של HOST_DIRECTORY.
• ‫PROJECT_ID הוא מזהה הפרויקט שבו מתבצעת ההעברה.
• ‫POOL_NAME הוא שם מאגר הסוכנים שבו רוצים להתקין את הסוכן הזה. אם לא מציינים את הדגל הזה, הסוכן מותקן במאגר transfer_service_default של הפרויקט.

הפקודה podman run תומכת בדגלים נוספים.

• ‫--enable-mount-directory טוען את כל מערכת הקבצים בספרייה /transfer_root במאגר התגים. אם מציינים את --enable-mount-directory, המערכת לא מחילה הגבלות על ספריות באמצעות הדגל -v.

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

• ‫--creds-file=/etc/gcloud/key.json מציין את הנתיב לקובץ פרטי הכניסה של חשבון השירות בפורמט JSON במאגר. הקובץ הזה מותקן באמצעות הדגל -v <var>HOST_PATH/TO/KEY.JSON</var>:/etc/gcloud/key.json:ro בפקודה.

• הערך --enable-s3 מציין שהסוכן הזה מיועד להעברות מאחסון שתואם ל-S3. אי אפשר להשתמש בסוכנים שהותקנו באמצעות האפשרות הזו להעברות ממערכות קבצים של POSIX.

• אם ההעברה היא מ-AWS S3 או מאחסון שתואם ל-S3, צריך להעביר את מזהה מפתח הגישה ואת המפתח הסודי באמצעות משתני סביבה:

    -e AWS_ACCESS_KEY_ID=AWS_ACCESS_KEY_ID \
    -e AWS_SECRET_ACCESS_KEY=AWS_SECRET_ACCESS_KEY
    ```
  

• ‫--env HTTPS_PROXY=PROXY מגדיר שרת proxy קדימה ברשת. הערך של PROXY הוא כתובת ה-URL של HTTP והיציאה של שרת ה-proxy. כדי למנוע כפילות של בקשות בהצפנת TLS, חשוב לציין כתובת URL מסוג HTTP ולא כתובת URL מסוג HTTPS. בקשות שעברו עטיפה כפולה מונעות משרת ה-proxy לשלוח בקשות יוצאות תקינות.

• ‫--agent-id-prefix=ID_PREFIX מציין קידומת אופציונלית שמופיעה לפני מזהה הסוכן כדי לעזור לזהות את הסוכן או את המחשב שלו במסוף Google Cloud . כשמשתמשים בתחילית, מזהה הסוכן מעוצב כך: prefix + hostname + OCI container ID.

• ‫--log-dir=LOGS_DIRECTORY משנה את הספרייה שאליה הסוכן כותב יומנים. ספריית ברירת המחדל היא /tmp/.

  אם לא ציינתם את --enable_mount_directory, אתם צריכים להוסיף את הקידומת /transfer_root לנתיב הזה. לדוגמה: /transfer_root/logs.

• ‫--max-physical-mem=MAX_MEMORY: ברירת המחדל של הסוכנים היא שימוש במאגר של 8GB. אם ברירת המחדל לא מתאימה לסביבה שלכם, אתם יכולים לציין את השימוש המקסימלי הרלוונטי בזיכרון בפורמטים הבאים:

  ערך של max-physical-mem	הגדרת זיכרון מקסימלית
  6g	‫6 ג'יגה-בייט
  6gb	‫6 ג'יגה-בייט
  6GiB	‫6 ג'יביבייט

  הערה: הדגל הזה לא מגביל את הזיכרון הכולל של מאגר התגים. כדי למנוע שגיאות OOM, צריך להגדיר את הערך הזה ל-50-60%
  מזיכרון ה-RAM הכולל של המאגר.

• ‫--network=DOCKER_NETWORK: ציון רשת Docker לקונטיינר הזה. ציון --network=host יכול לשפר את הביצועים על ידי הפחתת התקורה ברשת, אבל מאפשר גישה מלאה של מאגר התגים לרשת של המארח.

• ‫--kerberos-disable-pa-fx-fast מונעת מסוכנים להשתמש במשא ומתן מהיר עם Kerberos להעברות HDFS. משתמשים בדגל הזה אם המרכז להקצאת מפתחות (KDC) של Kerberos לא תומך בניהול משא ומתן של FAST.

פתרון בעיות

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

sudo podman run --ulimit memlock=64000000 -d --rm \
-v HOST_DIRECTORY:CONTAINER_DIRECTORY:Z \
-v HOST_PATH/TO/KEY.JSON:/etc/gcloud/key.json:ro \
gcr.io/cloud-ingest/tsop-agent:latest \
--project-id=PROJECT_ID \
--creds-file=/etc/gcloud/key.json:ro \
--hostname=$(hostname) \
--agent-pool=POOL_NAME

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

אישור החיבורים של הנציג

כדי לוודא שהסוכנים מחוברים:

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

   כניסה לדף Agent pools

   מאגרי הסוכנים מוצגים עם מספר הסוכנים המחוברים.

2. בוחרים מאגר סוכנים כדי לראות פרטים על סוכנים מחוברים.

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

מעקב אחר פעילות של סוכנים

אפשר להשתמש ב-Cloud Monitoring כדי לעקוב אחרי פעילות הסוכן.

המעקב זמין במאפיינים project, agent_pool ו-agent_id

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

שם המדד	מה מתואר	שימושים מומלצים
storagetransfer.googleapis.com/agent/transferred_bytes_count	המדד הזה מראה כמה מהר סוכן מסוים מעביר נתונים בכל המשימות שהוא מטפל בהן בנקודת זמן מסוימת.	התראה על ירידות בביצועים.
storagetransfer.googleapis.com/agent/connected	ערך בוליאני שהוא True לכל סוכן ש-Google Cloud קיבל ממנו לאחרונה הודעת דופק.	התראה על סוכנים שנכשלים הביצועים נמוכים ממספר הנציגים שאתם חושבים שנדרש כדי להשיג ביצועים סבירים דיווח על בעיה במחשבים של נציגי תמיכה

עדכונים לסוכנים

כדי לוודא שהסוכנים שלכם ב-Storage Transfer Service יקבלו את התכונות החדשות, תיקוני האבטחה ותיקוני הבאגים העדכניים ביותר, אתם צריכים להחליף מדי פעם את קובצי ה-container הישנים של הסוכנים בקובצי container חדשים.

קובץ האימג' של הקונטיינר של הסוכן האחרון נמצא ב-Artifact Registry תחת התג latest: gcr.io/cloud-ingest/tsop-agent.

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

השוואה בין גרסאות של מאגר תגים

כדי לראות את גרסת הקונטיינר של קונטיינר פעיל, מאחזרים את 12 התווים הראשונים של תקציר המניפסט שלו:

sudo docker inspect --format='{{index .RepoDigests 0}}' $(sudo docker inspect --format='{{.Image}}' CONTAINER_ID) | sed 's/.*sha256://' | cut -c1-12

משווים את התקציר הקצר הזה לעמודה Name שפורסמה ב-Artifact Registry.

כדי לראות את התקציר האחרון בשורת הפקודה, מריצים את הפקודה docker pull gcr.io/cloud-ingest/tsop-agent:latest כדי להוריד את התמונה העדכנית ביותר, ואז מריצים את הפקודה הבאה כדי לראות את התקציר הקצר שלה:

docker inspect --format='{{index .RepoDigests 0}}' gcr.io/cloud-ingest/tsop-agent:latest | sed 's/.*sha256://' | cut -c1-12

עדכון מאגרי תגים

כדי לבצע עדכון בהדרגה (rolling) של הסוכנים:

‫CLI של gcloud

1. אחרי שנכנסים לכל מכונה, מושכים את קובץ האימג' של הקונטיינר העדכני מ-Artifact Registry:

   sudo docker pull gcr.io/cloud-ingest/tsop-agent:latest

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

   sudo docker container list --all --filter ancestor=gcr.io/cloud-ingest/tsop-agent

3. כדי למחוק סוכן אחד:

   gcloud transfer agents delete --ids=CONTAINER_ID

4. התקנת סוכן חדש אחד:

   gcloud transfer agents install --pool=POOL_NAME --count=1 \
   --mount-directories=MOUNT_DIRECTORIES
   

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

Docker

1. אחרי שנכנסים לכל מכונה, מושכים את קובץ האימג' של הקונטיינר העדכני מ-Artifact Registry:

   sudo docker pull gcr.io/cloud-ingest/tsop-agent:latest

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

   sudo docker container list --all --filter ancestor=gcr.io/cloud-ingest/tsop-agent

3. כדי להפסיק סוכן אחד:

   sudo docker stop CONTAINER_ID

4. התקנת סוכן חדש אחד:

   sudo docker run --ulimit memlock=64000000 -d --rm \
   --volumes-from gcloud-config \
   -v HOST_DIRECTORY:CONTAINER_DIRECTORY \
   gcr.io/cloud-ingest/tsop-agent:latest \
   --project-id=PROJECT_ID \
   --hostname=$(hostname) \
   --agent-pool=POOL_NAME
   

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

Podman

1. אחרי שנכנסים לכל מכונה, מושכים את קובץ האימג' של הקונטיינר העדכני מ-Artifact Registry:

   sudo podman pull gcr.io/cloud-ingest/tsop-agent:latest

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

   sudo podman container list --all --filter ancestor=gcr.io/cloud-ingest/tsop-agent

3. כדי להפסיק סוכן אחד:

   sudo podman stop CONTAINER_ID

4. התקנת סוכן חדש אחד:

   sudo podman run --ulimit memlock=64000000 -d --rm \
   --volumes-from gcloud-config \
   -v HOST_DIRECTORY:CONTAINER_DIRECTORY \
   gcr.io/cloud-ingest/tsop-agent:latest \
   --project-id=PROJECT_ID \
   --hostname=$(hostname) \
   --agent-pool=POOL_NAME
   

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

עדכונים בינאריים של סוכנים

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

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

הפסקת סוכן

כדי לעצור סוכן, מריצים את הפקודה docker stop או podman stop במזהה הקונטיינר של הסוכן. כדי למצוא את המזהה ולהפסיק את הסוכן:

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

   כניסה לדף Agent pools

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

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

4. לוחצים על הפסקת הסוכן. הפקודה docker stop עם מזהה מאגר התגים הספציפי מוצגת.

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

   הערה: אם אתם משתמשים ב-Podman, צריך להחליף את podman ב-docker בפקודה.

   פקודת עצירה שמסתיימת בהצלחה מחזירה את מזהה הקונטיינר.

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

הפעלה מחדש של סוכן

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

מחיקת סוכן

כדי למחוק סוכנים ספציפיים, צריך לפרט אילו סוכנים פועלים במחשב.

Docker

sudo docker container list --all --filter ancestor=gcr.io/cloud-ingest/tsop-agent

Podman

sudo podman container list --all --filter ancestor=gcr.io/cloud-ingest/tsop-agent

לאחר מכן מעבירים את מזהי הסוכנים אל transfer agents delete:

gcloud transfer agents delete --ids=id1,id2,…

כדי למחוק את כל הסוכנים שפועלים במחשב, משתמשים בדגל --all או בדגל --uninstall. שני הדגלים מוחקים את כל הסוכנים במכונה; הדגל --uninstall גם מבטל את ההתקנה של קובץ אימג' של Docker של הסוכן.

gcloud transfer agents delete --all
gcloud transfer agents delete --uninstall

פרטי ההעברה של מערכת הקבצים

העברות מצטברות

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

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

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

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

פרטים על עקביות הנתונים

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

Storage Transfer Service משתמש בגודל הקובץ ובזמן השינוי האחרון שלו כדי לקבוע אם הוא השתנה. אם קובץ יעודכן בלי לשנות את השעה או הגודל של השינוי האחרון, ואתם תפעילו את האפשרות delete-objects-from-source, יכול להיות שתאבדו נתונים מהשינוי הזה.

כשמשתמשים בתכונה delete-objects-from-source, מומלץ מאוד להקפיא את פעולות הכתיבה למקור למשך ההעברה כדי למנוע אובדן נתונים.

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

• משכפלים את הספרייה שרוצים להעביר, ואז משתמשים בספרייה המשוכפלת כמקור להעברה.
• עוצרים את האפליקציות שכותבות לספריית קובצי המקור.

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

מכיוון שב-Cloud Storage אין מושג של ספריות, ספריות מקור ריקות לא מועברות.

חשוב: מומלץ מאוד לוודא שההעברה בוצעה בהצלחה לפני שמוחקים נתוני מקור. לשירות הזה אין אפשרות לשחזר נתונים ב-Cloud Storage.