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

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

NFSv3

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

NFSv4.1

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

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

מפרט NFSv3 NFSv4.1
רמות שירות נתמכות כל רמות השירות אזורי, אזורי וארגוני
תקשורת דו-כיוונית כן לא. התקשורת תמיד מתחילה על ידי הלקוח באמצעות יציאת השרת 2049.
אימות לא כן. נדרש אימות RPCSEC_GSS, שמוטמע באמצעות LDAP ו-Kerberos, שניהם זמינים ב-שירות מנוהל ל-Microsoft Active Directory.
תמיכה ברשימות של בקרת גישה (ACL) לקבצים או לספריות לא כן. אפשר להוסיף עד 50 רשומות של בקרת גישה (ACE) לכל רשימה.
תמיכה בקבוצות עד 16 קבוצות תמיכה במספר בלתי מוגבל של קבוצות כשמתחברים לשירות מנוהל ל-Microsoft AD.
הגדרת אבטחה ‫sys. יצירת ערוץ להרשאות שיתוף. ‫sys. יצירת ערוץ להרשאות שיתוף. krb5. מאמת את הלקוח והשרת. krb5i. מספקת אימות ובדיקות שלמות של ההודעותkrb5p. הפרוטוקול מספק אימות, בדיקות של תקינות ההודעות והצפנה של נתונים במעבר.
זמן האחזור של פעולות ללא החביון של הפעולות עולה ככל שרמת האבטחה שנבחרה גבוהה יותר.
סוג השחזור בלי שמירת מצב עם שמירת מצב
סוג נעילת הקובץ Network Lock Manager (NLM). הנעילה נשלטת על ידי הלקוח. נעילה מייעצת מבוססת-חכירה. הנעילה נשלטת על ידי השרת.
תמיכה בכשלים של לקוחות לא כן
תמיכה בגישה לשירותים פרטיים כן כן
תמיכה ב-Private Service Connect (GA מוגבל) עם פרוטוקולי IPv4 ו-IPv6 כן כן

היתרונות של NFSv3

פרוטוקול NFSv3 מציע הגדרה מהירה לגישת POSIX רגילה.

מגבלות של NFSv3

בהמשך מופיעה רשימה של מגבלות NFSv3:

  • אין אימות והצפנה של הלקוח והשרת.
  • אין טיפול בכשלים בצד הלקוח.

במקרים של מכונות NFSv3 שמשתמשות ב-Private Service Connect, נעילת קבצים ב-NFS כפופה להגבלות הבאות:

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

היתרונות של NFSv4.1

פרוטוקול NFSv4.1 משתמש בשיטת אימות RPCSEC_GSS, שמיושמת באמצעות LDAP ו-Kerberos כדי לספק אימות של לקוחות ושרתים, בדיקות של תקינות ההודעות והצפנה של הנתונים במעבר.

יכולות האבטחה האלה הופכות את פרוטוקול NFSv4.1 לתואם לדרישות התאימות המודרניות של אבטחת רשת:

  • משתמש ביציאת שרת אחת, 2049, לכל התקשורת, מה שמפשט את הגדרות חומת האש.

  • תמיכה ברשימות של בקרת גישה (ACL) לקבצים ב-NFSv4.1.

    • כל רשימת ACL תומכת בעד 50 רשומות של בקרת גישה (ACE) לכל קובץ או ספרייה. כולל רשומות של ירושה.

  • תמיכה בקבוצות ללא הגבלה כשמשתמשים בשילוב של שירות מנוהל ל-Microsoft AD.

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

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

  • יש תמיכה בשחזור עם שמירת מצב.

    • בניגוד ל-NFSv3,‏ NFSv4.1 הוא פרוטוקול מבוסס-מצב, מבוסס-חיבור ו-TCP. אחרי השחזור, אפשר לחזור למצב של הלקוח והשרת בסשן הקודם.

שירות מנוהל ל-Microsoft Active Directory

Managed Service for Microsoft Active Directory (שירות מנוהל ל-Microsoft AD) הוא לא דרישה מחייבת, אבל הוא הפתרון היחיד שמנוהל על ידי Google Cloudשתומך גם ב-LDAP וגם ב-Kerberos. שניהם נדרשים לפרוטוקול Filestore NFSv4.1.

מומלץ מאוד לאדמינים להשתמש בManaged Service for Microsoft Active Directory (שירות מנוהל ל-Microsoft AD) כדי להטמיע ולנהל LDAP ו-Kerberos.

כפתרון מנוהל, שירות מנוהל ל-Microsoft AD מספק את היתרונות הבאים: Google Cloud

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

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

  • תמיכה ב-POSIX RFC 2307 וב-RFC 2307bis, דרישות להטמעה של NFSv4.1.

  • אוטומציה של מיפוי משתמשים למזהה ייחודי (UID) ולמזהה ייחודי גלובלי (GUID).

  • אפשר ליצור משתמשים וקבוצות בשירות מנוהל ל-Microsoft AD או להעביר אותם אליו.

  • אדמינים יכולים ליצור אמון דומיין עם הדומיין הנוכחי של Active Directory ‏ (AD) ו-LDAP, שהוא מקומי ומנוהל עצמית. באפשרות הזו, לא צריך לבצע העברה.

  • הספק מספק הסכם רמת שירות (SLA).

בקרת גישה והתנהגויות נוספות

  • מנהלים את רשומות ה-ACE של Filestore NFSv4.1 ב-Linux באמצעות הפקודות הבאות:

    • ‫nfs4_setfacl: יצירה או עריכה של רשומות ACE בקובץ או בספרייה.
    • ‫nfs4_getfacl: הצגת רשימה של רשומות בקרת גישה בקובץ או בספרייה.

  • כל ACL תומך בעד 50 ACE. שש רשומות שמורות לרשומות ACE שנוצרות באופן אוטומטי על ידי פעולות של לקוח chmod. אפשר לשנות את רשומות ה-ACE האלה אחרי שהן נוצרות.

    רשומות ה-ACE שנוצרות אוטומטית ומייצגות את ביטי המצב מופיעות בסדר העדיפות הבא:

    • ‫DENY and ALLOW ACEs עבור OWNER@
    • ‫DENY and ALLOW ACEs עבור GROUP@

    • DENY and ALLOW ACEs של EVERYONE@

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

  • ב-Filestore NFSv4.1 אפשר לבדוק את הגישה הנדרשת רק במצב POSIX‏ RWX (קריאה, כתיבה והרצה). הוא לא יבדיל בין פעולות write append ובין פעולות write שמשנות את התוכן או את מפרט SETATTR. כלי השירות nfs4_setfacl מקבל גם את הקיצור RWX ומפעיל אוטומטית את כל הדגלים המתאימים.

  • ה-nfs4_getfacl לא מתרגם את העיקרון בעצמו. בכלי השירות nfs4_getfacl יוצגו הערכים המספריים UID ו-GUID עבור המנהלים. כתוצאה מכך, יוצגו המנהלים המיוחדים של OWNER@, GROUP@ ו-EVERYONE@.

  • לא משנה אם משתמשים בשירות מנוהל ל-Microsoft AD, כשעובדים עם AUTH-SYS ועם כלי השירות nfs4_setfacl, האדמינים צריכים לציין את הערכים המספריים UID ו-GUID, ולא את שמות המשתמשים. אי אפשר להשתמש בכלי הזה כדי לתרגם שמות לערכים האלה. אם לא מספקים את המזהה בצורה נכונה, מופעלת ברירת המחדל של מופע Filestore, והמזהה הוא nobody.

  • כשמציינים הרשאות כתיבה לקובץ, או אפילו לקבצים שמושפעים מ-ACE שעובר בירושה, ה-ACE חייב לכלול את הדגלים w (כתיבה) ו-a (הוספה).

  • כשבודקים את ההרשאות של SETATTR, התגובה שמוחזרת דומה ל-POSIX באופן הבא:

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

  • רשומה אחת של בקרת גישה כוללת גם הרשאות אפקטיביות וגם הרשאות שניתנות רק בירושה. בניגוד להטמעות אחרות של NFSv4.1,‏ Filestore לא משכפל באופן אוטומטי את רשומות ה-ACE שהועברו בירושה, כדי להבחין בין רשומות ACE שהן גם אפקטיביות וגם הועברו בירושה, לבין רשומות ACE שהועברו בירושה בלבד.

מגבלות של NFSv4.1

לפרוטוקול NFSv4.1 יש את המגבלות הבאות:

  • מגבלות כלליות

    • כשמשחזרים גיבוי, המופע החדש חייב להשתמש באותו פרוטוקול כמו מופע המקור.
    • כשמשתמשים בהגדרות אבטחה מאומתות של Kerberos, המשתמשים יכולים לצפות לזמן אחזור מסוים בפעולות. ההשהיה גדלה עם כל רמת אבטחה גבוהה יותר.
    • פרוטוקול NFSv4.1 לא תומך ב-ACE‏ AUDIT וב-ACE‏ ALARM.
    • אין תמיכה בבקרת הרשאות גישה לנתונים.

  • מגבלות ב-GKE

    אי אפשר לשלב את פרוטוקול NFSv4.1 עם Filestore multishares for GKE. התכונה הזו נתמכת רק ב-NFSv3. רשימה מקיפה של גרסאות GKE נתמכות לכל רמת שירות ופרוטוקול של Filestore זמינה בטבלת התאימות במאמר גישה למופעי Filestore באמצעות מנהל התקנים של Filestore CSI.

  • מגבלות של שירות מנוהל ל-Microsoft AD

    • אחרי שמגדירים את התכונה, לא מוחקים את הדומיין המנוהל של Microsoft AD או את ה-peering ברשת. אם תעשו זאת, לא תהיה יותר גישה לשיתוף Filestore.
    • מנגנון האימות היחיד שנתמך הוא RPCSEC_GSS, שמוטמע באמצעות LDAP ו-Kerberos (שניהם זמינים בשירות מנוהל ל-Microsoft AD).
    • כדי שמופע Filestore יצטרף לשירות מנוהל ל-Microsoft AD דרך VPC משותף, צריך להשתמש ב-gcloud או ב-Filestore API, ולא ב- Google Cloud.
    • שם הדומיין של שירות מנוהל ל-Microsoft AD לא יכול להיות ארוך מ-56 תווים.

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