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


אנו נפעיל את CentOS 7 בשרת החדש שלנו. יש לנו 6 x 300GB כונני raid6 פנימי לשרת. (האחסון הוא חיצוני במידה רבה בצורת תיבת פשיטה 40TB.) נפח פנימי מגיע כ 1.3TB אם מעוצב ככרך אחד. מערכת ה- sysadmin שלנו חושבת שזה רעיון רע מאוד להתקין את מערכת ההפעלה במחיצת 1.3TB אחת גדולה.

אני ביולוג. אנחנו כל הזמן להתקין תוכנה חדשה להפעלה ובדיקה, אשר רוב אדמות / usr / מקומי. עם זאת, מכיוון שיש לנו כ -12 מחשבים שאינם מבינים ביולוגים באמצעות המערכת, אנחנו גם לאסוף הרבה קרופט ב / הביתה גם כן. השרת האחרון שלנו היה מחיצה 200GB עבור /, ולאחר 2.5 שנים זה היה 90% מלא. אני לא רוצה שזה יקרה שוב, אבל אני גם לא רוצה ללכת נגד עצה מומחה!

איך אנחנו יכולים להשתמש בצורה הטובה ביותר 1.3TB זמין כדי לוודא שטח זמין כאשר והיכן זה נחוץ, אבל לא ליצור סיוט תחזוקה עבור sysadmin ??


92
2017-09-18 08:12




השתמש LVM ואת גודל בכל עת - thanasisk
@ thanasisk ב יהיה resisability הוא מיתוס, כי אין מערכת קבצים על לינוקס אשר היו יכולים להיות מקוצר באינטרנט. ext2 היה תיקון כזה בימי קדם. - peterh
@PeterHorvath - אז אתה שמח אם אני מחליף "גודל" עם "להרחיב"? - thanasisk
זה קצת לא מציאותי לצפות מה שאתה ההתקנה עכשיו עדיין להיות אופטימלי ב 2.5 שנים! והעובדה כי משתמשים לא מתמצא עושים בלגן הוא כל סיבה נוספת להפריד את מערכת ההפעלה מ נתונים. - JamesRyan
@PeterHorvath קראתי את ההערה שלך יותר מפעם אחת רק כדי שאוכל להבין את זה. כתבתם הייתם שמחים אם מערכת קבצים שיכולה להתקיים קיימת, והצבעתי על מערכת קבצים שעושה זאת. זה הכל. - gparent


תשובות:


הסיבות העיקריות (ההיסטוריות) לחלוקה הן:

  • ל להפריד בין מערכת ההפעלה לבין נתוני המשתמש והיישום. עד שחרור RHEL 7 לא היה נתמך נתיב שדרוג ושדרוג גרסה גדולה תדרוש התקנה מחדש ולאחר מכן למשל /home נתונים אחרים (יישום) על מחיצות נפרדות (או כרכים LVM) מאפשר לך בקלות לשמור על נתוני המשתמש ונתוני היישום ולנגב את המחיצה של מערכת ההפעלה (S).

  • משתמשים לא יכולים להיכנס כראוי ואת המערכת שלך מתחיל להיכשל בדרכים מעניינות כאשר אתה נגמר לחלוטין של שטח דיסק. מחיצות מרובות מאפשרות לך להקצות שטח דיסק קשיח שמור למערכת ההפעלה ולשמור על הפרדה בין האזור שבו משתמשים ו / או יישומים ספציפיים רשאים לכתוב (לדוגמה /home /tmp/ /var/tmp/ /var/spool/ /oradata/ וכו.) , - הפחתת הסיכון התפעולי של משתמשים ו / או יישומים רעים.

  • מכסה. מכסה הדיסק מאפשרת למנהל המערכת למנוע ממשתמש יחיד להשתמש בכל שטח פנוי, לשבש את השירות לכל שאר המשתמשים במערכת. מכסת דיסק בודדת מוקצה לכל מערכת קבצים, ולכן מחיצה אחת ולכן מערכת קבצים אחת פירושה רק 1 הדיסק. מחיצות מרובות (LVM) פירושו מספר מערכות קבצים המאפשרות ניהול מכסות מפורט יותר. בהתאם לתרחיש השימוש שאתה צריך, למשל, לאפשר לכל משתמש 10 GB בספריית הבית שלהם, 2TB בספריה / נתונים על מערך האחסון החיצוני ולהגדיר אזור שריטה משותפת גדולה שבה כל אחד יכול לזרוק מערכי נתונים גדולים מדי עבור ספריית הבית שלהם והיכן המדיניות הופך "מלא מלא" אבל כאשר זה קורה שום דבר לא נשבר.

  • מתן נתיבי IO ייעודיים. ייתכן שיהיה שילוב של SSD ו ספינינג דיסקים ו יעשה טוב כדי לטפל בהם אחרת. לא כל כך בעיה בשרת מטרה כללית, אבל נפוץ למדי setups מסד הנתונים היא גם להקצות spindles מסוימים (דיסקים) למטרות שונות כדי למנוע מחלוקת IO, למשל. דיסק נפרד עבור יומני העסקה, דיסקים נפרדים לנתוני מסד נתונים בפועל ודיסקים נפרדים עבור שטח זמני. .

  • אתחול ייתכן שיהיה צורך נפרד /boot מחיצה. מבחינה היסטורית כדי לטפל בבעיות BIOS עם אתחול מעבר למגבלת 1024 צילינדרים, כיום לעתים קרובות יותר דרישה לתמוך באמצעי אחסון מוצפנים, כדי לתמוך בבקרי RAID מסוימים, HBA שאינם תומכים באתחול מ- SAN או במערכות קבצים שאינם נתמכים באופן מיידי על-ידי המתקין וכו '.

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

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

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

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

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


104
2017-09-18 09:49



בהקשר של דבר הביצוע, אני חושב שזה גם שווה לציין כי, במקרה של מערכת קבצים הגשת תגובה מהירה יש צורך, ו 'df' יחזיר מידע שימושי הרבה יותר מהר מאשר 'du -s $ DIRNAME' - symcbean
אני לא בטוח שאני מסכים עם "עד ... RH7 ... אין נתיב שדרוג נתמך"עשיתי שדרוגים נתמכים מאז הזמן מתוך המוח, בהחלט משודרגות מערכות RH4-> 5 רק RH5 -> RH6 שחסר נתיב כזה, למיטב ידיעתי - ואני מקבל את ההרגשה RH יש ספג על ידי המשתמשים שלהם על חוסר זה. +1 עבור שאר התשובה מעולה, אם כי. - MadHatter
למה אתה מתכוון עם "עד שחרורו של RHEL 7 לא היה נתיב שדרוג נתמך"? האם RHEL תומך בשדרוגים בין הגרסאות העיקריות של RHEL 7 לבין קדימה? - Markus Hallmann
השדרוגים אמנם עבדו, אבל לפי כובע אדום המדיניות הכללית היא עדיין: Red Hat אינה תומכת בשדרוגים במקום בין הגרסאות הגדולות של Red Hat Enterprise Linux.  ועוד קצת ניואנסים Red Hat תומכת כעת בשדרוגים מ- Red Hat Enterprise Linux 6 ל- Red Hat Enterprise Linux 7 עבור מקרים ספציפיים / ממוקדים לשימוש בלבד ו הנה המדריך לבדוק - HBruijn


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

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

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

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

du -h -d 1 / 2> /dev/null

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


17
2017-09-18 08:38





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

שורש המשתמש יש תיקיית הבית שלה (/root) מחוץ ל /home בגלל זה. אם מערכת הקבצים מתמלאת בנסיבות מסוימות אפילו שורש לא יכול להיכנס ולא יכול לתקן את המערכת.

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


12
2017-09-18 08:23



על כמה מערכות קבצים (ext3 f.e.) אתה יכול לקבל מקום שמורות קטן עבור המשתמש שורש כדי למנוע את ההתנהגות. אתה צריך להשתמש מכסות כדי למנוע את זה, אותו עבור / tmp אשר נשכח לעתים קרובות. - Dennis Nolte
@DennisNolte שכחתי /tmp. תודה, אני אוסיף את זה לתשובתי. - Uwe Plonus
@DennisNolte שטח שמורות יעזור אבל אני חושב כי התחזוקה היא קשה יותר מאשר באמצעות מחיצות שונות כמו שאתה צריך להגדיר מכסות כראוי. - Uwe Plonus
אני חושב סיבה חשובה יותר /root להיות בחוץ /home זה על כמה התקנות /home יהיה על כונן רשת. במקרה של בעיה הרכבה על הרשת, קבצים של root להישאר נגיש. (זה עשוי להיות לעומת איך יש בדרך כלל עורך טקסט ב /bin, במקרה /usr לא עולה.) אני חושד שזה תרחיש נפוץ יותר בפועל, בימים אלה, מאשר /home מתמלאים כל הדרך. - Eliah Kagan


IMHO, לאחר מחיצה אחת כמו / היא סבירה למדי.

אבל אתה יכול להשתמש lvm (מנהל נפח לוגי). השתמש בכל הדיסק כקבוצת lvm, אך צור דיסקים לוגיים קטנים עבור /, / home, / usr וכל מה שהמערכת שלך מעדיפה. ואז לשים קצת ניטור על, כי אתה יודע, כאשר המערכת שלך מתחיל לקבל מלא ולהרחיב את הדיסקים שאתה צריך. lvresize ו resize2fs הוא כלים מקוונים ואתה יכול לעשות הרחבת מבלי להפעיל מחדש את השרת. עם זאת אתה לא יכול להקטין את הדיסקים, אז אתה צריך להתחיל באופן סביר קטן ולהגדיל שבו אתה רואה צורך.


10
2017-09-18 08:22





ישנן בעיות מינימליות סביב הגדרת מחיצה אחת גדולה של לינוקס, אבל יש לו rewards גדול.

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

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

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

יש מערכת פשוטה בשם LVM, המאפשרת את המהירות הזזת / שינוי גודל של "מחיצות" (במינוח שלה, כרכים). אבל על שרת מחלקת מקומית אחת, IMHO זה בדרך כלל לא נחוץ.


9
2017-09-18 08:43



איזה מין מנהל מזוכיסטי אוהב לשחק עם מפות מחיצה ??? החלק הכיפי הוא בניין הקרנל, אני יכול לקבל אמן??? - bishop
אמן! עכשיו על הטענה כי מנהלים אוהבים לשחק עם מחיצות, אני רק רוצה נגד זה עם העובדה כי לינוקס יש כנראה 100 סוגים שונים של סוגי קבצים בהתאם לדפוסי השימוש, בחירת מערכת filre הנכון למשימה מסוימת יכול מתכוון את ההבדל בין מערכת אופטימלית לבין מערכת לא פונקציונלית. ואולי אתה רק צריך את מערכת הקבצים במספר תיקיות. שם. - Lennart Rolland


ישנן שתי סיבות עיקריות למחיצות:

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

הסיבה הראשונה היא הברורה ביותר - אתה צריך לבודד אזורים שיתמלאו קבצים מאלו שאינם, ואתה רוצה במיוחד להגן, /, כדי למנוע מערכת unbootable. לדוגמה, ספריית / var היא בדרך כלל כאשר קובצי יומן יאוחסנו (var מייצג "משתנה") וזו הסיבה / var נוטה להיות מותקן על מחיצה נפרדת מ /.

הסיבה השנייה לעיל היא פחות מצוטט (שמעתי לאחרונה על קורס ניהול נפח Veritas כ 15 שנים) וזה באמת רלוונטי רק למערכות שבו אנשים רבים נכנסים וביצוע עבודה.

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

כמפתח תוכנה, אני נמאס במיוחד עם Ops המחלקה בניין וירטואלי מכונות עם תוכניות מחיצות מחשבה כי להגביל קשות את גודל / tmp, / home, / var ו / /, ללא קשר לשטח הדיסק הכולל זמין, אבל אז 'לא הר ברור אפשרויות כמו / usr או / לבחור בנפרד. מכונות אלה יהיה בדרך כלל לשים כל מה שנשאר מחוץ שטח דיסק ביקשת לתוך "/ דברים" נפח כי אתה בהכרח בסופו של דבר התקנת ו symlinking הכל, אבל זה בקושי נחמה. התוצאה הסופית היא שאנחנו לעתים קרובות לבלות זמן רב יותר דשדוש קבצים סביב שליחת הודעות דוא"ל מאשר לעשות כל עבודה אמיתית.

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

לכן הייתי אומר: אלא אם אתה בטוח 100% ביכולת שלך לחלק את המערכת באופן יעיל עבור מקרה השימוש הספציפי שלך, לא מחיצה בכלל.


3
2017-09-18 09:41



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


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

  • האם מערכת זו תינתן לעתים קרובות?
  • האם מערכת זו תשתמש על ידי משתמש אחד או יותר?
  • האם מערכת זו תשמש כשולחן עבודה או שרת, או שתיהן?

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

אתה תהיה מופתע כמה מעט מערכת לינוקס (נתונים קצת גדל) דורש לרוץ וכמה הוא נצרך על ידי גידול נתונים (בדרך כלל / var / opt / home / srv)

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

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

בשרת זה פחות סביר עבור תוכנות מותקנות להיות דינמי כמו עבור מערכת שולחן העבודה. זה גם חכם יותר יש mountpoints בפועל עבור רכיבי מערכת קבצים טיפוסי כגון / tmp / var / usr / home / opt / srv השימוש LVM כאן מומלץ לא לומר חובה.

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

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

Mounpoint /

  • 1GB (אם משתמשים ב- mountpoints נפרד עבור / var / usr / opt / home / tmp)
  • +10 או אפילו +20 GB אם אתה משתמש כמערכת שולחן עבודה עם נפרד / הביתה

אם באמצעות mountpoint / הביתה

  • להקצות את כל שטח פנוי אם נעשה שימוש, / ne ne

אם באמצעות mountpoint / opt

אם באמצעות mountpoint / usr

  • זה אחד מסובך תלויים במידה רבה על בסיס התוכנה המותקנת

אם באמצעות mountpoint / var

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

אם באמצעות mountpoint / tmp

  • שקול tmpfs קיים מוקצה / tmp ל- RAM
  • לשקול יישומים מסוימים עשויים לכתוב הרבה נתונים כאן

2
2017-09-18 14:18





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

אז, כמה תצפיות:

  • 1.3 TB הוא לא כונן גדול יותר. 2 TB הוא יותר או פחות סטנדרטי בגודל כונן SATA בעולם שולחן העבודה בימים אלה.

  • התקנה של כל לינוקס Distro סביר לדרוש יותר מ 100GB. אין ספק, הגודל עבור / (שורש) ו (swap) צריך להיקבע בקלות כמו מספרים עליון על ידי נדיב יתר על המידה אותם (עבור שורש) או על ידי הנחיות תצורת המערכת (החלפה).

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

  • אתה כנראה צריך לשים את התוכנה המיוחדת שלך לתוך partion נפרד (נקודת הר עבור / usr / מקומי / bin וכו '), כך שתוכל לשמור על זה על פני עדכוני מערכת ההפעלה ומחיצה מחיצת השורש. אחרת אתה מתמודד עם האפשרות כי תצטרך להתקין מחדש את היישומים שלך "מיוחד" תוכנה לאחר שדרוג מערכת ההפעלה / לתקן / מה.

  • אם אתה רוצה לדאוג לניהול המערכת שלך, הייתי שואל שאלה אחרת: מהו תהליך ההתאוששות מאסון לאחר הבניין תופס את האש ואת השרתים ותיבות RAID נהרסים? אלא אם הנתונים החשובים לך נשארים לגמרי בראש שלך, זו שאלה שכל משתמש צריך לשאול את אנשי ה- IT / sysadmin אנשים. האסטרטגיה צריכה לכלול שאלות כמו "איך נוכל לשכפל את החומרה שאנחנו צריכים" ו "כמה זמן זה ייקח לפני שאנחנו יכולים לחזור ולהפעיל". חלק מהדיון אודות וירטואליזציה של השרתים שלך עשוי לסייע בפתרון בעיות הקשורות לתלות בחומרה ולהעברת דברים לגיבוי ללא צורך בהגדרת תצורה של מערכת ההפעלה (מאחר שניתן להגדיר אותה לפעול בסביבת התקן "רכה" שאינה משתנה, גם כאשר החומרה הבסיסית שונה לחלוטין)

  • באופן דומה, ייתכן שתרצה לשאול מהי האסטרטגיה להגנה על נתוני המשתמש מפני הפסדי נתונים של שגיאות בתוכניות ובמשתמשים. שמירת קובץ ריק על הטיוטה הגדולה באמת של עבודת המחקר שלך, או שיש למשתמש להקליד את הפקודה הלא נכונה (rm -rf * לדוגמה) תגרום לאובדן נתונים בדיוק כמו רעידת אדמה או שריפה או נזק פיזי אחר. פתרונות שחזור קבצים בודדים הם קצת שונה (או יכול להיות!) מאלה שימושי ביותר עבור התאוששות מאסון הסיטונאי.

  • -

2
2017-09-23 13:10