כמה מילים על ביטול הדרישה מהבנקים לאחסון מידע ומערכות בארץ

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

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

נתחיל בהתחלה ובחלק החשוב שבו לבנקים לקח זמן להבין ולהכיר בכך שב"מלחמה" בין תשתיות On Prem לתשתיות ענן של ספקי ענן ציבורי רציניים (אהמ… לא ענני צעצוע) – ידם של ספקי העננים הציבוריים תהא על העליונה, גם אם נלך לפי מחירים ניתן לבנות אצל ספקי הענן הציבורי תשתית וירטואלית טובה שיכולה להתחרות ולנצח מחיר של תשתיות On Prem בכל אספקט של מחיר מול ביצועים, PPW ועוד.

כיום אפשר לאמר שכל הבנקים כבר החלו לעבוד ברצינות על קונטיינריזציה, על Scaling רוחבי ועל שימוש בתשתיות הענן הציבורי. כך לדוגמא, שרותי SAAS שבעבר לא הוכנסו ואילו עתה הם חלק אינטגרלי מתשתית הוירטואלית של הבנק בענן הציבורי. עתה הבנקים יוכלו בעצם לשכור שרותי PAAS/SAAS/IAAS מספק הענן לפי דרישות שונות וללא מגבלות ("אין כרגע שרתים נוספים, זה תקוע בחו'ל" – אמר לי יבואן גדול בארץ שניסיתי לסייע ביבוא 3 ספרות של שרתים אך לפני מספר חודשים) שקיימות פה בארץ.

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

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

מהרגע שספקי הענן הציבוריים הגדולים (אמזון, גוגל, אז'ור) יפעילו את חוות השרתים והתשתיות שהם מקימים בארץ, הבנקים יתחילו להעביר ולהקים את התשתית, כולל תשתית פרודקשן, על ה-Region הישראלי. יחד עם זאת, אין זה אומר שמחר הבנקים יעבירו את ה-Main Frame אל תשתיות הענן הציבורי (כדאי לזכור שכל הבנקים חתומים על חוזי שרות די קשוחים עם IBM שלמיטב ידיעתי – די אוסרים על העברת התשתית ל-AWS או לספקי ענן אחרים … זולת תשתיות IBM בענן, אבל גם אז – לא בטוח שהבנקים ירצו לעבור לזה), כך שבסופו של יום, תשתית ה-MF עדיין תהיה מוגנת כמו שהיא מוגנת היום בכל הבנקים, רק שמעתה הבנקים יצטרכו לעבוד קצת יותר קשה על אבטחת מידע.

תהיה נוספת שעולה במקומות שונים, היא החובה למסור מידע פיננסי לבתי משפט אמריקאיים, מכיוון שספקי הענן הציבורי הינם חברות אמריקאיות. למיטב ידיעתי, כל הבנקים קיבלו תשובות על כך ואני אזכיר רק אספקט טכני אחד: כל בנק יכול לעשות מה שהוא רוצה עם התשתית הוירטואליות שלו בענן, ואף אחד אינו מונע מהבנק להצפין כל ביט אפשרי גם מעל רמת ה-OS (כלומר – משהו יותר מאשר איזה ביט-לוקר), כך שמקרה הכי גרוע – לספק יש במקרה הטוב גישה ל-Block Device (ה-EBS) של ה-VM, לדוגמא, אך אין לו גישה לשמות משתמשים/סיסמאות או גישה למידע שמוצפן בתוך ה-VM מעבר לרמת ה-OS, כך שהוא מקבל בלוק ג'יבריש מבחינתו והוא אינו יכול להכריח את הלקוח לתת פרטי גישה. במילים אחרות: צו משפטי לא ממש יגרום למסירת נתונים שהבנק אינו חפץ למסור.

ולבסוף – עניין חסכון בכח אדם שהוזכר בכתבה. לי זה רק גורם לחייך: מעבר לענן כולל לימוד תשתיות ענן ציבוריות, לימוד Kubernetes/OpenShift ומערכות נוספות אחרות – מה שמצריך הגדלת כח האדם, ולא צמצום. במילים אחרות – סביר להניח שהבנקים לא יעברו מחר בבוקר בתשתיות ענן ל-Serverless, כך שאותם אנשי תשתיות בבנק – יצטרכו גם לתחזק את ה-VM שירוצו בענן הציבורי, בנוסף או במקום התשתיות שרצות On Prem, כך שאם החישוב שלי נכון – אין שום חסכון בכח אדם.

לסיכום: ברכותיי לבנקים שקיבלו את ההיתר ועתה יוכלו לעבור ולהקים את התשתיות בענן ציבורי. כולי תקווה שהבנקים ישכילו להקים תשתיות שהם Scalable רוחביות עם כמה ש-פחות תשתיות On Prem Legacy ישנות (תשתיות Active/Active או Active/Passive למיניהן??), ורק איחולי הצלחה לכל המשתתפים באותם פרויקטים.

ניתוח פריצה ל"אטרף" / Cyberserve

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

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

ואז מגיע התות בעוגת הקצפת – ה-DB של אתר הדייטים של הקהילה הלהט"בית "אטרף" – "נפרץ" והם גנבו את המידע, ובשביל להכניס אנשים ללחץ, הם שחררו דוגמית של 1000 רשומות בקובץ CSV.

מכיוון שהקבוצה הפורצת מחוברת לטלגרם (תחת הכינוי Black Shadow כמובן, לא צריך להיות גאון כדי לראות אם זו הקבוצה הנכונה, פשוט רואים כמה מנויים יש להם), והקבוצה נותנת להורדה את קבצי הדוגמית, הורדתי את הקובץ בכדי לבדוק האם כדברי העיתונות – עוד דקה כל הומו/לסבית שבארון צריכים לארוז את החתול או הכלב, לשכור עורך דין או לחפש חלון מהיכן לקפוץ ולאמר "ביי" לעולם….

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

  1. אני חושב שיש מקום למספר משתמשים בקהילה לפגוש עורכי דין ולהרים תביעה נגד אתר אטרף. לפחות לפי הטבלה, אין אפילו "המלחה" של הסיסמאות, כך שלו האתר היה עולה ברגעים אלו, היה לנו מופיע "שישו ושמחו". האתר יצטרך לכל הפחות לאפס את כל סיסמאות המשתמשים ולשלוח אימייל עם בקשת קביעת סיסמא חדשה, ואולי, אולי לדאוג לכך שהסיסמאות "יומלחו".
  2. כל מי שחושש שמיד כל עם ישראל ואחותו ידעו שהוא הומו או ההיא לסבית – יכול להירגע. הטבלה לא ממש מכילה פרטים ישירות מתעודת זהות. יש שורות של "שם כינוי", "שם חבר", ו"שם משתמש", ובהסתכלות על השמות, רבים בחרו לעצמם "שמות" שיותר מתאימים לסרטי פורנו ("אק חתיך"!, "morfios" – שמישהו ילמד את הבחור קצת אנגלית או משהו), כך שאם לא מכירים אותך, הסיכוי ש"תוצא מהארון" בכח – די קטן, אם כי יש מצב שאחרים שכן מכירים אותך – ידעו עליך, הואיל והטבלה מכילה מספרי טלפון וכתובות אימייל.
  3. פרטים קריטיים כמו מספר תעודת זהות, מספר כרטיס אשראי (כולל CVV ותוקף) אינם נמצאים בטבלה כך שאם קניתם דרך אטרף כרטיסים להופעות/אירועים – פרטיכם לא יופיעו בטבלה שפורסמה.
  4. אלו שנכנסו לפאניקה, שמא היוודע לבין/בת הזוג שהוא הומו/היא לסבית ולפיכך הקשר הולך להיות בטל מהר חיש קל ברבנות – התשובה לכך היא "לא". ברבנות עדיין יש מחשבה שכל משיכה מינית שאינה כמו של "סטרייט" ניתנת לכיבוי בשניות ספורות, ולכן הם לא יאשרו גירושים, אלא אם לבן/בת הזוג יש הוכחות על קיום מערכת יחסים מחוץ למערכת היחסים הרשמית.
  5. אני רוצה לציין כאן את מה שציינתי בבלוג זה בעבר הרחוק – אם את/ה מעוניינ/ת לצ'וטט עם מישהו/י, בין אם זה לצורך העברת זמן או לצורך חיפוש קשר כלשהו – אל תתן פרטי אמת, תרים כתובת אימייל פיקטיבית, ובקיצור – אל תעביר שום פרט אמיתי. המצב בארץ ימשיך להיות גרוע מבחינת אבטחת מידע, ואת זה אני יכול להבטיח.

לסיכום: מ-1 עד 10, הייתי נותן ציון של 4 לפריצה זו. לא רק שהם פרצו למשהו שהוא כמעט "דלת פתוחה", הם גנבו נתונים של אתרים שמופנים כלפי ציבור ללא מידע סודי. המידע של אטרף היה אמור להיות מוצפן (אם מישהו לא היה עצלן שם) ואני חושב שכדאי לתבוע את החברה על כך ועל הנזק הנפשי שהם גורמים למשתמשיהם, אבל חוץ מזה .. לא רואה עם הפריצה הזו חדשות מרעישות.

ה-NAS החדש

בשנים האחרונות היו לי מספר מכונות ששימשו כ-NAS ל-LAB שלי, ועל מנת להשאיר תשתית אופטימלית, צמצמתי את כמות המכונות שברשותי, כך שישארו רק מכונות שאני צריך, וכך במהלך החצי שנה האחרונה התפטרתי ממספר שרתים ומספר מכונות NAS שבניתי. מכונה אחת שירתה אותי בנאמנה במשך 8 שנים, וה-NAS האחרון שהיה רץ על שרת 2U של Supermicro – נתרם (ללא הדיסקים כמובן).

החלטתי לבנות מכונה חדשה, שהדברים החשובים לי בה היו:

  1. קיבולת גבוהה של דיסקים (הכנסתי בה 17 דיסקים, עוד 2 בקרוב)
  2. שקטה לגמרי
  3. נגישות מהירה לחלקים שונים כמו החלפת דיסקים/מעבד/זכרונות/כרטיסים וכו'
  4. בלי כל מיני "צעצועים" כמו RGB.

תודות לחברי היקר רפי אינשטיין, מצאתי את המארז האידיאלי – Antec P101 Silent שנמכר בארץ במחיר של 370 שקל. רכשתי את המארז, הוא הגיע והתחלתי להרכיב. להלן המפרט שאני משתמש במכונה:

  • מעבד: AMD Ryzen 2700 (תיכף אסביר מדוע)
  • זכרון: 64 ג'יגהבייט
  • לוח אם: ASUS X470-F
  • כרטיסי רשת: כרטיס רשת של Mellanox (דור שני) עם חיבורי +SFP ל-10 ג'יגה, וכרטיס רשת Broadcom NetXtreme BCM5715 (כרטיס עם 2 חיבורי 1 ג'יגה)
  • כרטיס תצוגה – GT 710 של Zotac (אני מאוד ממליץ על הכרטיס הזה. הוא נותן חיבורי מסך פופולריים – HDMI,DVI,VGA, והחיבור שלו הוא PCIe X1, כך שהוא לא יתפוס כניסות PCIe חשובות)
  • כרטיס Intel Optane 900p – הכרטיס הוא SSD מיוחד בגודל 280 ג'יגה. יקר (תציצו בלינק) – אבל שווה כל שקל אם אתם משתמשים ב-ZFS ובחיבור של 10 ג'יגהביט ומעלה.

מבחינת דיסקים, אלו הדיסקים שבפנים:

  • 8 דיסקים בגודל 6 טרהבייט של טושיבה מסידרת ה-Performance (כ-7200 RPM) – בהחלט סוסי עבודה
  • 6 דיסקים SSD SATA – סמסונג 860 EVO בגודל 512 ג'יגהבייט
  • 2 דיסקים SSD NVME מסוג סמסונג 960 EVO בגודל 512 ג'יגהבייט

(ברצוני להודות לחברת דגן מולטימדיה על הסיוע המהיר בכבלים ומפצלים – בלעדיהם הכל היה נתקע)

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

פתגם עתיק אומר "לכל 2 יהודים יש 3 דעות" – אז שאלתי לתומי וקיבלתי מגוון המלצות והצעות (רובם בהודעות פרטיות), אז להלן ההצעות ומדוע לא בחרתי בהן:

  • Proxmox, Xen Server, UnRaid – כל הפתרונות הללו מתאימים אם רוצים להריץ פתרון וירטואליזציה בראש ובראשונה על הברזל עם סבירות גבוהה שזה יהיה הברזל היחידי (כלומר "השרת היחידי"). במקרה שלי רציתי NAS שיהיה עצמאי ושיתן שרותי קבצים (ועוד מספר שרותים שירוצו כקונטיינרים עם Podman), כך שפתרונות אלו אינם מתאימים לי.
  • XPEnology – זהו פתרון בקוד פתוח של Synology והוא יכול להתאים ללא מעט אנשים, כל עוד הדרישות הן צנועות. במקרה שלי, אוטומטית הוא לא היה מכיר במחצית מהכרטיסים במחשב, אז הוא ירד מהאופציות עוד בהתחלה.
  • FreeNAS – זהו פתרון מעולה למי שמחפש פתרון "קופסתי פשוט" – כלומר קופסא שזורקים אליה כמות דיסקים, מתקינים FreeNAS, מבצעים כמה הגדרות פשוטות ומתחילים לעבוד. הבעיות עם פתרון כזה הן שמערכת כזו היא מצומצמת וקשה להוציא ממנה ביצועים משמעותיים (תאמינו לי, השתמשתי ב-FreeNAS במערכת הקודמת ובזבזתי ימים שלמים עליה) כשצריך מהירות גבוהה יותר מ-10 ג'יגהביט.
  • אובונטו – תהליך הטמעת ה-ZFS בהפצה זו הוא יותר "work in progress" וה-LTS (כלומר Long term support) זו בדיחה לא מוצלחת, למען האמת. מוותר על התענוג.

בסופו של דבר בחרתי ב-CentOS 8 (ליתר דיוק – CentOS 8.2.2004) מכמה סיבות פשוטות:

  • רקורד מוכח ב-Long Term: ה-NAS שהיה לי לתקופה של 8 שנים הריץ CentOS 6 (ששודרג בהמשך ל-CentOS 7) והוא נתן לי יציבות מעולה.
  • ZFS על CentOS – אחד הדברים הכי מנוסים והכי יציבים. לא מעט אלו שמריצים לינוקס עם ZFS מהמפתחים של ZFS on Linux (וכיום OpenZFS) מריצים ZFS על CentOS.
  • קלות התקנה: 3 פקודות. יבוא מפתח, 2 פקודות DNF – ויש ZFS במערכת.
  • לא חסר תמיכה.

יחד עם זאת: האם אמליץ על ה-OS הזה ל-ZFS לאנשים שאין להם נסיון בלינוקס או ZFS? לא. בוא נהיה מציאותיים: CentOS ו-ZFS מצריכים השקעה בלימוד דברים שונים, ואם מחפשים חיים יותר קלים (ולא מצפים לביצועים בשמיים) – אז FreeNAS ואובונטו הם פתרונות טובים.

מבחינת הגדרות, הגדרתי את הדברים כך:

  • 8 דיסקים מכניים הוכנסו ל-Pool בתצורת RAIDZ-2 (כלומר RAID 6 למי שלא מכיר את ZFS) כך שקיבלתי כ-43.7 טרהבייט מקום פנוי
  • 6 דיסקים SSD SATA הוכנסו ל-Pool שגם הוא בתצורת RAIDZ-2 כך שקיבלתי 2.78 טרהבייט מקום פנוי
  • SSD NVME אחד "הוקרב" לטובת ה-OS עצמו (כך שהוא אינו חלק מ-ZFS. יש היום תמיכת Boot ב-GRUB2 מ-ZFS אבל ליתר בטחון אני מעדיף שדיסק ה-OS יהיה עצמאי ולא כחלק מ-ZFS ואם הוא נדפק, דיסק און קי עם CentOS ו-ZFS יכול לשמש כתחליף חרום).
  • ה-SSD NVME השני חולק ל-2, כך שכל Pool מקבל 240 ג'יגהבייט כ-Cache.
  • ה-Optane חולק ל-2 כך שכל Pool קיבל 40 ג'יגהבייט ZIL. מכיוון ש-Optane 900p (והגירסה היותר מתקדמת שלו 905P או גירסאות ה-Enterprise – ה-P4800X) ניחנים ב-Latency הרבה יותר נמוך מכל SSD שקיים בשוק (הוא לא משתמש ב-Flash) – ביצועי הכתיבה – גבוהים.

אז .. איך הביצועים? להלן צילום מסך (לחצו להגדלה).

מה שרואים בתמונה זו הוא שכל הדיסקים המכניים כותבים במקסימום מהירות אפשרית, וה-ZIL (שמופיע כ-logs) מקבל כמות זהה של נתונים לכתיבה (ה-ZIL בעצם מקבל את הנתונים שאמורים להיכתב – לפני שהם מגיעים לדיסקים הקשיחים לכתיבה מעשית). בפועל זה נראה יותר כך:

כלומר קצב הכתיבה נע בין 300-800 מגהבייט לשניה, תלוי מה הנתונים ותלוי אם ה-ZFS יכול לדחוס אותם (לדוגמא: קבצי VMDK שהם flat – יש לא מעט מקום לדחיסה, כך שבמקרים כאלו אני מקבל קצב כתיבה ממוצע של 770 מגהבייט לשניה). מבחינת קצב קריאה – אני מקבל רצוף בסביבות ה-700 מגהבייט לשניה (זה מה שקורה כשמנסים להכניס כרטיס רשת Mellanox ConnectX-3 לתוך כניסת PCIe 2.0, טופל בעת כתיבת פוסט זה)

וכך זה נראה במכונת Windows וירטואלית שרצה תחת vSphere 6.7 כאשר ה-Datastore מגיע מ-NFS V3 והתוצאות הן ללא טריקים של Cache, Write back וכו'.

עד כה המערכת רצה ללא תקלות, אך יחד עם זאת – יש לי עוד דברים לבדוק, כמו העניין הדי תמוה שכתיבה על הדיסקים SSD שנמצאים ב-pool משלהם – מהירות הכתיבה מגיעה עד 160 מגה במקום 550 מגה (לא קשור לכרטיס HBA כלשהו) ועוד כמה דברים פה ושם שאני רוצה לבדוק, לחבר למערכת ניטור וכו' וכו'.

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

המחשב שלך מכניס לך פרנסה? קרא את הפוסט

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

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

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

וכאן מתחילה הבעיה של חיפוש פתרון: אתרים רבים מתחזים לתת פתרונות – בכך שהם דוחפים רכישה של מוצר (שכמובן לא יעזור לפתרון הבעיה), התמיכה הוובית של מיקרוסופט (answers.microsoft.com, אני מעדיף אפילו לא לקשר לשם!) שווה בערך כמו לשאול את החתולים שלי לגבי הצעות לפתרונות, ובפורומים שונים ברוב המקרים תקבל כמה וכמה תשובות, כאשר רובן כלל לא רלוונטיות או לא נכונות. מה לגבי טכנאי מחשבים שונים ששומעים עליהם את הלל כמה הם מעולים ומקצועיים? חלקם אולי כאלו, אך לצערי חלקם הגדול עדיין לא יודע אפילו לשאוב את כל הפרטים מ-Windows (רמז, זה קצת יותר מ-Event Viewer) לגבי התקלות. דוגמא? נסו לפתור תקלה עם Code 10 שלא נפתרת גם כשהתקנתם דרייברים מחדש, או דרייברים אחרים.

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

  1. הדבר הראשון שחשוב לעשות, הוא לרכוש/להשתמש במחשב יעודי שעליו יותקנו וירוצו רק האפליקציות המשמשות לעבודה ותו לא. לא משחקים, לא כלים אחרים, לא מייל, וכו'. רק את התוכנות שצריך.
  2. הדבר השני החשוב – הוא לעבוד בתצורה של 2 דיסקים תמיד. דיסק אחד הוא דיסק עם מערכת הפעלה, ודיסק שני הוא דיסק מדיה לאחסון התכנים, כאשר הכל נשמע מבחינת תכנים בדיסק השני ואם עובדים על יצירת/עריכת תכנים – עובדים אך ורק על הדיסק השני. מחירי דיסקים SSD ירדו וממשיכים לרדת וכדאי לנצל זאת, ואם אין מקום במחשב הנייד לדיסק SSD שני, תמיד קיימים דיסקים SSD חיצוניים או שאפשר לרכוש מתאמים חיצוניים שלתוכם מלבישים דיסקים SSD שבמקור יועדו להיות פנימיים (זה גם יוצא יותר זול, אל תהיו iJustine וחבריה).
  3. הדבר השלישי שהוא הכי חשוב – הוא לרכוש או להתקין תוכנת גיבוי שיודעת לגבות דיסקים (לא רק לגבות קבצים). תוכנות כמו Macrium Reflect (היא חינמית וניתנת לשדרוג תמורת סכום נמוך) יכולה לגבות את המחשב שלכם לדיסק חיצוני או NAS כל כמה זמן שתרצו ולכן מומלץ להגדיר לה פרק זמן גיבוי של לפחות אחת לשבוע לדיסק חיצוני או NAS. הגיבוי עצמו יכלול רק את ה-SSD שכולל את מערכות ההפעלה. את התכנים תגבו בצורה אחרת לדיסק חיצוני או NAS.
  4. עבדו בחוכמה – אל תחליפו/תשדרגו תוכנות רק כי שמעתם דברים חיוביים לגבי תוכנות אלו ואחרות. קודם כל צרו גיבוי ואז התקינו את מה שאתם רוצים.
  5. רוצים לחזור אחורה? הפעילו את ה-Boot Media שתוכנת הגיבוי יוצרת (זה דרך כלל דיסק און קי שהתוכנה מאפשרת ליצור), התחברו לדיסק החיצוני או ל-NAS ושחזרו גיבוי אחרון. אם שמרתם את קבצי המדיה/פרויקטים וכו' בדיסק השני בלבד, השחזור לא ידפוק שום דבר בתהליך. אם לעומת זאת "בטעות" שמרתם על הדיסק הראשון, העבירו לדיסק שני ואז תשחזרו.

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

בהצלחה.

לכידת וידאו ושינוי ה-Workflow

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

אחד הדברים ששאפתי להתחיל לבצע לאחרונה קשור להקלטות וידאו לערוצי היוטיוב שלי. יש לי כרגע 2 מצלמות די פשוטות (G85 של פנאסוניק ו-D7100 של ניקון) וכנראה שאני ארכוש עוד אחת (תלוי בתקציב שיהיה לי – A6600 של סוני או GH5S של פנאסוניק. אני לפעמים צריך להקליט ברזולוציית 4K ב-60 פריימים לשניה) ואיכות הוידאו שהן מקליטות היא טובה, אך אינני מרוצה מהקבצים עצמם: הם מוקלטים עם קידוד H.264.

אחד הדברים הבעייתיים ביותר עם קידוד H.264 לוידאו הוא שהמקודד הזה בנוי להזרמת או ניגון ישיר של הוידאו בנגן תוכנה או חומרה, אבל הוא לא בדיוק מתאים לעריכה, הואיל ותוכנת העריכה צריכה לחשב (דרך ה-CPU במקרים רבים) היכן כל פריים נמצא, וכשמבצעים Scrubbing בעורך הוידאו, יכולים לראות במקרים רבים שהמחשב "משתהה" עד שהוא מציג וידאו וגם כשהוא מציג, לפעמים לאחר מספר שניות הוא "נחנק". יוטיוברים רבים מצלמים במצלמות סוני/ניקון/קאנון/פנאסוניק שמקליטות ב-H.264 ואת זה הם עורכים, ובדרך כלל אם כל מה שעושים קשור לחיתוך חלקים שונים, הוספת LUT, כמה אפקטים, סינכרון אודיו/וידאו ויצוא וידאו להעלאה ליוטיוב (כלומר Workflow די קטן יחסית לאדם אחד) – אז אפשר להסתדר עם H.264.

העניין הוא שבדרך כלל כשרוצים איכות וידאו גבוהה ולא דחוסה כל כך (H.264 ו-H.264 דוחסים בלי רחמים) וגם רוצים לערוך קבצים בנוחות, צריך וידאו בפורמט "ביניים" (באנגלית: Mezzanine) בקידוד אחר, קידודים כמו Apple ProRes, DNxHD/DNxHR, CineForm. הבעיה – כמעט שום מצלמה בסקטור ה-Prosumer (כזו שעולה פחות מ-4000 דולר) לא מאפשרת להקליט ישירות בקידודים כאלו, את זה היצרניות שומרות למצלמות הוידאו המקצועיות, ה-CX00 של קנון, ה-FX של Sony וכו' וכו'. מה שכן, במקרים רבים הן מאפשרות להקליט באיכות הרבה יותר גבוהה דרך יציאת ה-HDMI במצלמה. יש צורך להגדיר 2-3 דברים במצלמה ואפשר להקליט ברזולוציות גבוהות ובאיכות צבע יוצאת מן הכלל.

וזה בדיוק מה שרבים עושים עם מסכים חיצוניים קטנים שגם מקליטים, כמו משפחת Atomos: מחברים את המצלמה אל המסך החיצוני הקטן, ובמקום להקליט לכרטיס ה-SD (או בנוסף) – מקליטים במסך עצמו שכולל בד"כ SSD שליף או כרטיס SD משלו. מחירים מסכים מקליטים כאלו מתחילים בסביבות ה-500$ ונעים לכיוון ה-5000$.

למי שרוצה להשיג את אותו אפקט ויש לו מחשב רציני, אפשר להשתמש בכרטיס לוכד וידאו עם כניסת HDMI (דוגמאות: Elgato 4K60 Pro,Elgato Cam link 4K, ויש עוד חברות אחרות) ועם תוכנה כמו OBS Studio. שיטה כזו גם מאפשרת "הלבשה" של LUT ופונקציונות רבות נוספות, כולל תמיכה בקידודי ביניים כפי שציינתי לעיל, וגם להקליט בקידוד H.264 עם Bit-rate הרבה יותר גבוה ממה שהמצלמה מאפשרת פנימית. הבעיה: קידודי הביניים למרות שהם אפשריים מבחינת התוכנה – אינם דבר כה יציב, בלשון המעטה, ויש גם צורך במחשב חזק ומהיר על מנת לבצע את העבודה הזו.

התקופה הנוכחית בה וירוס הקורונה משתולל בחוץ, זימנה סיטואציה די מעניינת: אנשים התנפלו על כל דבר אפשרי שקשור לשידור וידאו דיגיטלי: מצלמות Webcam (מכל הסוגים), לוכדי וידאו זולים (במיוחד של Elgato ו-AverMedia) וכתוצאה מכך המחירים זינקו במאות אחוזים. לעומת זאת, כרטיסי לכידת וידאו מקצועיים שאינם תומכים כברירת מחדל באפליקציות וידאו כמו סקייפ, ZOOM וכו' – מחירם נשאר ואף ירד בחלק מהמקרים/

וכך מצאתי לאחרונה באמזון את הכרטיס המופיע כאן משמאל. זהו כרטיס של חברת Blackmagic ושמו: DeckLink Mini Recorder 4K. הוא יכול לקבל קלט HDMI ו-SDI. (אפשר, אגב, לרכוש את אותו כרטיס בארץ בקישור הזה, אולם יש לקחת בחשבון זמן המתנה של שבועיים, תתעלמו מכך שכתוב שהוא אינו במלאי. הם מייבאים רק כשמזמינים).

היתרון של כרטיס כזה הוא בכך שהכל נעשה על שבב חומרה יעודי ולא על ה-CPU של המחשב, הווה אומר: כל עוד יש במחשב SSD מהיר (עדיף NVME כמו Samsung Evo 970 Plus) ואת הכרטיס הזה, אפשר להקליט וידאו ישירות מהמצלמה ללא צורך בהקלטה על כרטיס SD – ואפשר לבחור מקודדי ביניים או מקודד סופי עם איכות שאפשר לשנות מקצה לקצה, והקידוד יהיה בזמן אמת. בשבילי זה חוסך גם עבודה עם OBS וגם עבודה בעורך הוידאו עם מקודדים סופיים, וכתוצאה מכך העריכה נהיית הרבה יותר קלה ו… אין צורך בקבצי פרוקסי, תודה לאל!

הזמנתי כרטיס כזה (דרך ushops, אמזון לא מאפשרים להזמין אותו ישירות לארץ) ובהמשך הדרך אני אשדרג ל"אח" היותר גדול שלו: Decklink Quad HDMI Recorder, מה שיאפשר לי לחבר במקביל עד 4 מצלמות עם תמיכה של עד 4K ב-60 פריימים לשניה (אם המצלמה מאפשרת זאת כהקלטה חיצונית כמובן).

לסיכום: שיטה זו ו-Workflow זה אינו מתאים לכולם. אלו שמשתמשים במצלמות וידאו מקצועיות, כבר עובדים עם מקודדי ביניים ואותן מצלמות מייצאות פורמטים כאלו. לעומת זאת, אני עם ה-Workflow הזה חוסך לעצמי את ההמרה מ-H.264 למקודד ביניים, וההמרה בסוף (ליצוא) לא תחליף את הקבצים שקודדו עם מקודדי הביניים. אלו יוכלו להישאר אצלי באחסון על דיסקים יותר איטיים וכשיהיה צורך אעביר את הקליפים בין האחסון האיטי למהיר (שנמצא במחשב) ולהיפך וכל זאת מבלי לאבד איכות וידאו בהקלטה.

אשמח לשמוע את דעתכם ומה אתם הייתם משנים ב-Workflow.

לינוס, ZFS וכמה נקודות בנושא

הכל התחיל במייל שכתב לינוס טורבאלד, ה"אבא" של ליבת לינוקס (אוקיי, יש כאלו שיתעקשו שנקרא לזה GNU/LINUX) – הוא התייחס לנקודה ישנה וקצת כואבת, שאי אפשר להכניס קוד של ZFS ללינוקס על ה-Kernel של לינוקס. הרשיונות לא ממש תואמים. (בעיה ידועה שאנשים מעשיים לא מתייחסים אליה כיום, למען האמת: אם לקוח מגיע אליי ומבקש ממני לבנות לו מפרט לשרת לצרכי AI, מטבע הדברים אני אכלול כרטיסים של nVidia אבל הדרייבר ל-NVIDIA הוא בינארי לחלוטין, האם לפסול את הכרטיסים בגלל שהדרייבר הוא כזה? כמובן שלא, כי הכרטיסים המתחרים מציעים בערך מחצית מהביצועים).

לינוס מוסיף בסוף המייל כי ZFS זה "באזז" והוא מבקש "אל תשתמש ב-ZFS".

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

נתחיל מהמציאות הפשוטה: ZFS על לינוקס אינו פרויקט נסיוני. גם בגירסה הנוכחית (0.8.2 נכון לכתיבת שורות אלו) ובגירסה הקודמת (0.7.13) אין שום באג ידוע שגורם לקריסת מערכות. המערכת יציבה ונמצאת במקומות שונים פה בישראל ובעולם כמובן – בפרודקשן. לא מדובר באיזה פרויקט שמורכב מ-2 אנשים שמתחזקים אותה בשעות הפנאי שלהם ועושים טובה לאנושות שהם עונים לפוסטים/מיילים. יש לא מעט חברות מעורבות בפרויקט שתורמות קוד ותיקוני באגים נון סטופ, וזו אחת הסיבות שעמותת OpenZFS החליטה יחד עם כל החברות המשתתפות בפיתוח ZFS לפני שנתיים – להעביר את כל הקוד לגירסה חדשה שתיקרא OpenZFS ושתהיה מבוססת על ZFS for Linux עם כל השינויים שקיימים לפלטפורמות אחרות (BSD, Illumos, Mac OS וכו') כך שברגע שתצא גירסת OpenZFS 1.0 – היא תהיה תואמת לכל הפלטפורמות וכל קוד שיכנס יקומפל אוטומטית מול כל הפלטפורמות ואם הקוד לא רץ על אחת מהפלטפורמות, מגיש הקוד יצטרך לתקן זאת.

ZFS היא, בניגוד למערכות File systems אחרות בלינוקס – אינה רק file system, היא הרבה יותר, היא מייתרת את הצורך בהגדרות Partitions, מייתרת את הצורך בהגדרות ושימוש LVM, מפשטת תהליכים בשיתופים דרך NFS, iSCSi, CIFS/SMB, מאפשרת snapshots בצורה הרבה יותר טובה ממה ש-LVM נותן, הוא כולל מערכת Cache טובה וכשזה מגיע לתחזוקה שוטפת, זו המערכת היחידה שיודעת לעשות תהליך resilver (תהליך בו המערכת עוברת על כל המידע בסקטורים השונים בדיסק, בודקת אם הכל תקין ומה שהיא מוצאת לו תקין – היא מעתיקה למקומות אחרים תקינים, והכל ברקע), ויש ל-ZFS עוד פונקציות רבות שלא תיארתי ופונקציות בהחלט מעניינות שמפותחות בימים אלו, והכי חשוב – הכל רץ על לינוקס.

יש כאלו שיציינו שיש את BTRFS שזו מערכת מעולה. צר לי, היא לא כזו מעולה, גם כיום, בכל מה שקשור ל-RAID-5/6 ויש רק הפצה אחת שמתקינה אותה כברירת מחדל: SuSE. הפצות שמקובלות בגופים גדולים כמו RHEL, CentOS, Ubuntu או שלא כוללים תמיכה ל-BTRFS (כל מה שמבוסס על רד-האט) או שתצטרך לעבוד ידנית כדי להגדיר BTRFS. בהפצה כמו אובונטו 18 ומעלה, תצטרך לעבור חתיכת תהליך (בהצלחה עם זה, ואגב, והתהליך לא כולל שום שימוש בכל הפונקציות הרציניות של BTRFS כמו sub volumes במאמר) כדי לבנות מערכת עם BTRFS.

יש כמובן גם FIle systems אחרים כמו EXT4 ו-XFS שהן טובות, אבל כשיש בעיות כלשהן שהמערכת לא מוכנה לעבוד עם ה-Journaling – הסיוטים מתחילים (במיוחד ב-XFS. רק לפני מס' שבועות קיבלתי פניה מיצרן שרתים שהתקין ללקוח שלו מערכת SAP כשכל המערכת וה-DATA יושבים מקומית ולאחר כמה חודשים, המערכת קרסה. הוא ביקש ממני להציץ, והמצב מבחינת XFS היה כל כך קטסטרופלי, שההמלצה שלי היתה פשוטה: תפרמט ותשחזר מאפס מגיבוי) וכאן ל-ZFS יש יתרון בכך שהוא בודק אחת לשבוע או אחת לחודש (כפי שתגדיר ב-crontab) את תהליך ה-resilver ואפשר תמיד לראות את המצב עם פקודת zpool פשוטה.

אינני טוען ש-ZFS מתאים לכל שימוש. על מכונות וירטואליות, על מכונות דסקטופ/לאפטופ עם דיסק יחיד – אין ממש יתרון גדול ל-ZFS (חוץ מהפונקציונאלית של snapshots אם אתה רוצה לשדרג חבילות או את כל המערכת לגירסה חדשה ומעוניין לחזור אחורה אם יש בעיות, דבר שדי בעייתי לעשות עם LVM – במיוחד בהפצות כמו ubuntu, Debian ששם כברירת מחדל בהתקנה לא משתמשים ב-LVM) ויש בהחלט מקום ל-File systems כמו EXT4 או XFS.

לסיכום: ZFS זו מערכת רצינית שמצריכה מעט למידה של המושגים. הפצה כמו אובונטו 19 מאפשרת לך לראשונה להתקין מערכת לינוקס עם ZFS ב-root עם הצפנה, העברת snapshots מוצפנים, אבל חשוב לשים לב שזה נסיוני (בגלל זה החלוקה המוזרה לשני pools – התמיכה ב-GRUB2), יש קהילה משגשגת ויש גם חברות שמוכרות מוצרים ותמיכה ל-ZFS על לינוקס (והפצות אחרות). ZFS לא מתאימה לכולם ולא מתאימה לכל מצב, אך יחד עם זאת, ZFS זה לא buzz.

שימוש ב-NVME SSD RAID לעריכת וידאו מקצועי

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

בחלק מהמקרים, אצל עורכים יותר מקצועיים, קיים מכשיר DAS המחובר דרך SFF-8087 או דרך Thunderbolt למחשב. המכשיר מכיל מספר דיסקים מכניים והעריכה נעשית ישירות מול אותו מכשיר בסטודיו של העורך. היתרון בשיטה זו – אין צורך בערימת SSD חיצוניים פר צילום/פרויקט, מספיק אחד כדי להעביר את הוידאו מהשטח (אם צלם חיצוני או חברת צילום חיצונית מצלמת והעורך הוא מישהו אחר שיושב במקום אחר) אל מכשיר ה-DAS.

הבעיה הגדולה כיום היא שקבצי וידאו הולכים וגדלים גם במצלמות סמי מקצועיות. מצלמות כמו GH5 או Sony A7 R4 ומצלמות מקצועיות כמו Canon C300, או RED או ARRI למיניהן – מקליטות וידאו באיכות יותר ויותר גבוהה וכל שניה של וידאו תופסת יותר ויותר שטח, ואנחנו מדברים רק על וידאו, לא אודיו, לא Assets, לא אפקטים ושום דבר אחר, כך שמגיע מצב שגם SSD חיצוני טוב מתחיל להיות איטי – והמצב לא הולך להשתפר (נכון, קיים קידוד H.265 HEVC, אבל לא מומלץ להקליט איתו וידאו כי קידוד כזה יותר מתאים ל-Delivery מאשר לעריכה). הבעיה מתגלית בחומרתה לא רק בזמן ה"טיול" ב-Timeline, אלא במיוחד בקידוד הוידאו – ה-Encoder יסיים את הקידוד אך יקח עוד דקות ארוכות עד שהתהליך יסתיים מכיוון שצריך להעתיק את הנתונים מהמחשב המקומי ל-DAS (כן, גם אם בחרת לקודד ישירות ל-DAS, המחשב קודם מבצע את הפעילות בדיסק המקומי).

אחד הפתרונות הטובים הקיימים לבעיה כזו הוא שימוש ב-RAID NVME. זהו כרטיס ריק שלתוכו אנחנו מכניסים מקלות SSD NVME בחיבור M.2. עד 4 כרטיסים כאשר כל כרטיס מגיע עד גודל 2 טרהבייט. את הכרטיס נגדיר כ-RAID-0.

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

היתרון בשיטה זו הוא עצום. לא חשוב איזה חיבור יש לך לאחסון חיצוני גדול (סטורג', DAS) – ה-RAID המדובר נותן ביצועי מהירות של עד 15 ג'יגהבייט לשניה. סתם לשם השווה: אם יש לך DAS של 4 דיסקים, תקבל אולי מהירות של 800 מגהבייט לשניה, כך שההבדל התיאורתי במהירות הוא כמעט פי 20.

ה-RAID שאני מתאר יכול להיות עד גודל 8 טרהבייט, אבל כל מי שקנה פעם SSD NVME M.2 יוכל לאמר לכם שמחירי המקלות לא זולים. התשובה לכך פשוטה: לא חייבים ישר לרוץ ולרכוש את המקלות של 2 טרהבייט פר מקל. אפשר לדוגמא להתחיל עם מקלות SSD של סמסונג מסידרה 970 Evo Plus בגודל חצי טרהבייט. כל מקל כזה עולה 600 שקלים ב-KSP/IVORY, והכרטיס לעיל עולה 250 שקלים כולל משלוח מאמזון. ההרכבה וההגדרות די פשוטות, אולם צריך מחשב נייח די עדכני ודי חזק עם לפחות 2 כניסות PCIe 3 X16 ותמיכה ב-BIOS ב-PCI bifurcation. אם המחשב הנייח שלך הוא בן שנתיים-שלוש ויש לו 6-8 ליבות, סביר להניח שתוכל להטמיע פתרון כזה. אני מקווה בשבועות הקרובים להעלות וידאו כיצד להגדיר זאת.

פתרון זה, כמו שציינתי, הוא למחשב נייח/תחנת עבודה. מה עם מחשבים ניידים? לצערי חיבור Thunderbolt 3 לא מספק מספיק רוחב פס לעשות את הטריק הזה. (ה-RAID הזה משתמש בכל רוחב הפס של PCIe 3.0 X16).

משהו חשוב: ה-RAID הזה לא מחליף אחסון מקומי למערכת הפעלה (אלא אם יש לכם מחשב נייח עם מעבדי Skylake X או מעבדי Threadripper), כך שאם יש לכם מעבד 6-8 ליבות מהדור השביעי ומעלה, עדיין תצטרכו את הדיסק הקשיח המקומי או SSD המקומי שיש לכם במחשב על מנת לעבוד עם מערכת ההפעלה והאפליקציות.

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

נקודות לגבי שרתים לבניה עצמית

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

כפי שכתבתי בפוסט קודם בסידרת ה-My Labs: אני מעדיף לבנות את ה-LAB שלי בעזרת מחשבים עם מעבדי דסקטופ של AMD מסידרת Ryzen 7 2700. יש לך 8 ליבות ו-16 נימים, עד 64 ג'יגהבייט זכרון, ו-2-3 מכונות כאלו אמורות להספיק לכל LAB קטן..

אמורות.. חשבתי לעצמי..

ואז הגיעו כמה הצעות מעניינות. מצד אחד הרעיון שלי לגבי VDI זול (שמצריך מעבדים כמו Xeon E5 V4), או בקשות לגבי בניית סטורג' מבוסס 100 דיסקים 3.5", בקשות לגבי סטורג' משולב במתודת Scale Out, וירטואליזציה HCI במחיר זול, הקשחת חומרה, וגם בקשות כמו ניטור אפליקציות שונות ב-Scale out ב-Scaling של כמה עשרות Nodes אך לא במובן של אם "זה רץ", אלא מה ההשפעה מבחינת Latency, זמנים וכו'.

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

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

  • שרתי מותג בתצורת 1U או 2U ישנים הם אסון מבחינה אקוסטית כשמתחילים להרחיב אותם. קחו כל שרת 1U ותוסיפו כרטיס או 2. לא חשוב מה הכרטיסים שתוסיפו. ברגע שתפעילו את הכרטיסים ותפעילו מחדש את השרת, תראו איך המאווררים עולים בכמה דציבלים טובים מבחינת רעש, גם אם יש קירור ממזגן או שהמעבדים לא עושים כמעט כלום. הכרטיסים חוסמים חלק מהקירור, שבב ה-BMC שאחראי על ניהול כל הקירור וה-PWM של המאווררים – מחליט על דעת עצמו להעלות ברמה את מאמצי הקירור (למרות שאין ממש צורך. שרת יכול לעבוד יופי גם אם הטמפרטורה בשרת היא 25 מעלות לדוגמא). בשרתים 2U הבעיה פחות קיימת – עד שאתה מכניס כרטיסים של 40 ו-56 ג'יגהביט (לדוגמא: מסידרת ConnectX של Mellanox) – ואז שוב הדצבילים עולים. זו, אגב, אחת הסיבות מדוע שום ספק ענן ציבורי רציני לא רוצה להשתמש בשרתים כאלו – הם בנויים ברמת Engineering של "כיסוי תחת" מושלם, למרות שהציוד יכול לתת יותר ולעבוד בטמפרטורות יותר גבוהות (מה שחוסך לספק הענן כסף בקירור).
  • אחת הבעיות הנוספות בשרתי מותג היא שהטכנולוגיה ישנה למרות שטכנולוגיה חדשה יותר היתה קיימת בעת יצור השרת. קחו שרתים כמו R610 ו-R620 (או G7 ו-G8 של HPE) ותגלו שרוב תושבות ה-PCIe (אם לא כולם) הם PCIe 2.0 ולא PCIe 3.0. רוצה לחבר JBOD ב-SAS 12G? זה פשוט או שלא יעבוד או שיעבוד לאט כי השבבים של LSI ו-Adaptec לדוגמא דורשים PCIe 3.0.
  • בעיה נוספת שאינה נמצאת רק בשרתי מותג היא עניין הזכרון: אם אין לך מקלות זכרון DDR3 ECC כשכל מקל הוא 32 ג'יגהבייט, תוכל להכניס מקסימום 16 מקלות של 16 ג'יגהבייט ולקבל מהירות של 1333 מגהרץ. כל מקל נוסף שתכניס בתושבות הזכרון הפנויות – ומהירות הזכרון של כל השרת יורדת ל-1033 ואם אתה ממלא את כל התושבות (18 או 24, תלוי בלוח אם) – זה ירד גם ל-800 מגהרץ עלובים, כך שמקסימום הזכרון שניתן להשתמש בלוח אם עם מעבדי Xeon E5 V1 או V2 במהירות זכרון מקסימלית – היא 256 ג'יגהבייט זכרון עם מקלות של 16 (מחירי המקלות של 32 ג'יגהבייט זכרון עדיין גבוהים).

מהבעיות – נעבור לפתרונות:

  • מבחינת לוחות אם, אני מעדיף לעבוד עם Supermicro. הם מייצרים לוחות מעולים שידידותיים לשינויים. כך לדוגמא ניתן להוסיף תמיכת NVME לתוך ה-BIOS, גם כש-NVME לא היה קיים בזמן יצור הלוח. אפשרי גם להתקין Coreboot (בחלק מהמקרים, לצרכי אבטחה) במקום ה-BIOS הרגיל, וכל הציוד הקיים על הלוח נתמך גם בהפצות לינוקס ישנות ללא צורך בחיפוש אחר מודולים ודרייברים, כולל שינוי מהירויות מאווררים, שליטה על ה-IPMI ללא צורך להיכנס ל-BIOS וכו'.
  • אחת הנקודות שחשוב לשים לב בבחירת לוח אם – זה הגודל שלו. אפשר למצוא לוחות מעולים של Supermicro אך שהם בגודל EE-ATX. בניגוד לרושם הראשוני, הגודל במקום רבים מופיע כ-Extended EATX ואנשים לא שמים לב לכך (כולל הח"מ) ולוח כזה לא נכנס לשום מארז שרת (וגם לא ברוב מארזי ה-Tower, אלא אם בא לכם להצטייד במקדחה לחורר דברים, לחתוך פלסטיקים וכו' וכו'), ולכן אם רוצים לרכוש לוח אם כזה, כדאי לבחור ATX או E-ATX בלבד.
  • בחירת מעבדים – הנה נקודה שנשמעת די טריוויאלית אך היא אינה כה פשוטה שמסתכלים מקרוב. בלוחות SuperMicro מסוג X8D או X9D אפשר להשתמש ב-Xeon E5 V1 (שלא כתוב עליו V או V1) ובמקרה של X9D אם תכנון הלוח (כתוב כ-Revision על הלוח) הוא מגירסה 1.20 ויש BIOS אחרון – אפשר להשתמש ב-Xeon E5 V2. בלוחות X10D אפשר להשתמש במעבדי Xeon E5 V3 או Xeon E5 V4 עם זכרון DDR4 ECC. אתם לא מחפשים כח עיבוד רציני? אפשר או לרכוש לוחות עם האות S במקום D (ה-S מציין לוח מעבד יחיד ו-D מציין זוג מעבדים) ואז מכניסים מעבד אחד או שאפשר לרכוש 2 מעבדים כשבמעבד מצויינת האות L (הכוונה Low Power).
  • מעבדים וטכנולוגיה – סביר מאוד להניח שכל מי שרוצה לרכוש שרתים, ירצה להריץ עליהם פתרון וירטואליזציה כלשהו, ואין שום בעיה להריץ vSphere על כל המעבדים, החל מהדור ראשון ועד הנוכחי, אבל אם רוצים להשתמש בטכנולוגיית וירטואליזציה כמו SR-IOV (פוסט על הנושא בבלוג העסקי בקרוב) – חייבים מעבד Xeon E5 V4 ומעלה. אפשר לנסות על Xeon E5 V3 אבל המימוש קיים בערך ב-60-80% מהמקרים, תלוי בלוח, ב-BIOS וכו'.
  • מבחינת מארז ללוח אם לשם בניית השרת – ישנם לא מעט מארזי 3U זולים שניתן לרכוש מ-eBay והם יחסית קלים במשקל כך שלא יהיה צורך לשלם סכומי עתק על המשלוח. עם מארזים כאלו ניתן להשתמש בקירור יותר קונבנציונאלי למעבדים, ניתן להשתמש במאווררים 120 מ"מ שקטים וניתן להשתמש בספק ATX רגיל (מי שמעוניין יכול כמובן להכניס 2 ספקי Flex ATX לשרידות), ואם הולכים על מארז 4U, אפשר להשתמש בפתרון קירור עם רדיאטור בגודל 120 מ"מ לכל מעבד ולהשאיר את המאוורר האמצעי לקרר את את הלוח, זכרון וכו' – זה בהחלט מספיק.
  • מעבדים – ניתן למצוא מעבדים זולים מהסידרת Xeon הראשונה, V2 וגם חלק ממעבדי V3 (אלו עם ה-4 ליבות). מעבר לכך – המחיר קופץ. פתרון די פופולרי שקיים הוא לרכוש מעבדים מאותה משפחה מסידרת ES שהם בעצם Engineering Samples. חשוב לציין: אלו מעבדים שאין להם כיתוב שם רשמי על המעבד (כתוב מספר כלשהו ו-Confidential) ובחלק מהשרתים (במיוחד בשרתי מותג) הם לא יעבדו. המהירות שלהם תהיה פחותה מהמהירות הרשמית בהשוואה לדגם הרשמי ויכול להיות (סיכוי מאוד קטן) למצוא בעיית תאימות כלשהי באפליקציות מסויימות (לא נתקלתי בבעיה כזו). אין שום אחריות למעבדים כאלו מצד אינטל. גם כאן, Supermicro הם היחידים שאני מכיר שכל ה-ES עובדים בלי בעיה על לוחות האם של החברה. אפשר לקחת פחות סיכון ולרכוש את ה-QS שהם בעצם שוחררו זמן ממש מועט לפני היציאה הרשמית של המעבד, ושם מהירות השעון היא כמו המעבד הרשמי ואם היו באגים, המיקרוקוד שקיים ב-BIOS כבר מטפל בבעיה. בכל מקרה אני לא ממליץ לאף חברה לרכוש מעבדים דוגמאות ES או QS.

עוד דברים שיכולים לעזור:

  • חושב לעבוד במהירות 10 ג'יגה? (לפחות מהסטורג' שלך למכונות). במקום לחבר Point to point, יש Switch של חברת MicroTik ב-2 גרסאות. יש גירסה של 8 פורטים ו-16 פורטים, חיבורי +SFP. ה-8 פורטים עולה כמה מאות שקלים וה-16 פורטים עולה בסביבות ה-1300 שקל, כך שתצטרך לרכוש כרטיסי רשת וכבלי DAC/TwinAX. חשוב לשים לב – אם אתה עובד עם vSphere אז לא לרכוש כרטיסי רשת ישנים של Chelsio (הם לא נתמכים ואין VIB שנותן להם תמיכה).
  • מחירי UPS צנחו וכיום ניתן לרכוש UPS של 1000VA ולחבר אותו ל-3 מכונות למקרים של הפסקות חשמל קצרצרות (חצי דקה עד דקה גג, תלוי בעומס של המכונות שלך) או כמיישר מתח. מחיר של UPS כזה הוא בסביבות 400-500 שקל (תלוי היכן קונים).
  • אם אתה מתעקש לקחת שרתי מותג ורוצה מקסימום שקט, קח שרת 2U ואל תכניס בו דיסקים (למעט 1 או 2 ל-OS ואם זה ESXI – אז תשתמש ב-Disk On Key בחיבור שקיים לך על לוח האם). אחד הדברים ששמתי לב בכל הקשור לאיוורור – הוא שאם יש דיסקים, המאווררים חייבים ליצור לחץ סטטי גדול מאוד כדי להכניס מספיק אויר לקירור. אם אין דיסקים, לא צריך לחץ סטטי חזק והשרת יותר שקט.

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

כמה מילים על UPS

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

עד לפני חודשים ספורים ב-LAB שלי כל המכונות היו שרתי מותג ושרת האחסון מבוסס לינוקס+ZFS היה מכונת Core i5 פשוטה עם 32 ג'יגה זכרון ודיסקים. אם היתה מתרחשת הפסקת חשמל והחשמל היה חוזר לאחר זמן מה, כל השרתים היו מופעלים מיידית, אך מכיוון שלשרתים לוקח זמן רב להגיע למצב שהם מטעינים את ה-OS, הזמן ה"פנוי" הזה היה די והותר עבור מכונת ה-i5 לעלות, לבדוק שהכל תקין מבחינת ZFS, לייצא את ה-NFS ושאר שרותים, כך שכשהשרתים היו מתחילים לעלות, כל השרותים שהם זקוקים להם חיצונית – היו זמינים להם. את ה-UPS עצמו לא הייתי צריך כי רוב הזמן המכונות הוירטואליות היו סטטיות "ריקות" שמריצות Hypervisor (כך ש-reboot פתאומי לא היה ממש משנה משהו) ומכונות ה-VM היו עולות בין כה מחדש, כך שב-99% מהמקרים הפסקת חשמל לא היו ממש מזיקות לי. כל המערכת כולה, החל מהרגע שהחשמל חזר ועד שהכל למעלה – עולה תוך 10 דקות בערך.

UPS באופן עקרוני יכול לעזור במצבים מסויימים. אם יש לך מכונת דסקטופ עם GPU יוקרתי וביצעת Overclock לדוגמא למעבד ו/או לזכרון, המכונה תעבוד 24/7 ותצרוך הרבה יותר חשמל מהמצב הרגיל, מה שאומר ש-UPS של 1000VA (וולט אמפר) יחזיק לך אולי דקה או 2 גג. אתה יכול להגדיר את ה-UPS כך שלא יעשה כלום או שיתחיל את תהליך הכיבוי או להריץ סקריפט משלך כשאין חשמל. כמה זה עוזר? תלוי. יש מקרים ש-Windows לדוגמא בעת כיבוי מציג חלון שאומר שאפליקציות X,Y,Z פתוחות והחומר לא נשמר, מה שדי מבזבז את הזמן שנשאר בסוללת ה-UPS. בלינוקס ובמק המצב יותר טוב והמערכת כשמקבלת פקודת כיבוי מתחילה לכבות את השרותים במקביל עד לחלק ה-poweroff שמורץ ואז המכונה תיכבה מעצמה בצורה חלקה ללא נזקים.

בזמן האחרון ה-LAB שלי קיבל תפנית חדה ועד סוף חודש הבא (תלוי בשירותי השליחויות בחו"ל, מכס וכו') יתווספו ל-LAB שלי עוד 5 שרתים באורח קבע ושרת האחסון שלי יוחלף בשרת עם מעבד Xeon מרובה דיסקים ו-SSD. שרת כזה לא עולה תוך 45 שניות כמו השרת הנוכחי וכששרתי הוירטואליזציה השונים לא מקבלים שרותי NFS ו-iSCSI בזמן boot – הם גם לא מפעילים את המכונות הוירטואליות שאמורות לרוץ עליהם, ולכן מה שאצטרך לעשות בעצם זה לחבר את ה-UPS ל-Raspberry Pi ולדגום את ה-UPS. אם יש הפסקת חשמל, הוא ישלח פקודות דרך ipmitool כדי לכבות את המכונות ושרת הקבצים כמכונה אחרונה. חזר החשמל? הסקריפט ירוץ הפוך (שרת קבצים קודם כל, בדיקת שרותים, ולאחר מכן הפעלת שרתי הוירטואליזציה).

אז למי ששואל אותי לגבי עמדתי בעניין UPS – כן, אני ממליץ לכל אחד, במיוחד שזה עולה רק בסביבות ה-400 שקל ויכול להציל אותך מהפסקות חשמל קצרצרות (כמו שיש כאן באזור). למי שיש LAB לעומת זאת, אני ממליץ לעשות חישובי צריכה ולקנות את ה-UPS בגודל המתאים (אם יש לך נסיון בלינוקס אז אתה לא חייב את הגירסה עם הכרטיס רשת. יש בלינוקס את NUT ואתה יכול לעשות איתו את הכל ופשוט לחבר את ה-UPS לאיזה מכשיר Raspberry Pi או תואם). אני לא אהבתי כל כך UPS כי אני אוהב לחיות מבחינת טכנולוגיה "על הקצה" ואוהב לעשות Stress לציוד שברשותי (ושהינו בבעלותי) ולבדוק אם המערכת חיה גם אחרי אירועי הפסקות חשמל, חום וכו', אבל גם אני עכשיו עם UPS 🙂

התובנות שקיבלתי מה-LAB שלי

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

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

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

מה שאני כן ממליץ זה לבחור את אחת מהאופציות הבאות:

  • לקחת מחשב דסקטופ שקיים אצלכם, למלא אותו בזכרון (במידה וצריך), להתקין עליו כרטיס רשת (אני ממליץ על כרטיס המבוסס על שבבים של אינטל), לרכוש SSD זול ולהתקין לדוגמא ESXi (יש צורך בכרטיס הרשת הנוסף מכיוון ש-ESXi אינו תומך בכניסות רשת שנמצאים על לוח האם).
  • לרכוש מחשב מבוסס AMD Ryzen 7 (כמו ה-2700) ולמלא אותו בזכרון בהתאם לתקציבכם, SSD זול, כרטיס רשת – ולהתקין ESXI. במקרה הזה תקבלו פי 2 יותר ליבות בהשוואה למעבדים של אינטל ותמיכה ב-עד 64 ג'יגהבייט זכרון.

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

מכאן – נעבור לתובנות.

בקיץ האחרון היו לי מספר שרתים 1U ו-2U של חברות כמו Dell, HPE, IBM. כולם שרתים ישנים (מעבדי E5-2620 דור ראשון ושני) – והיו לי בין 3 ל-8 מכונות, תלוי בחודש ובדילים שהשגתי, מה שמכרתי ועוד. הסביבה שבא נמצאו השרתים היתה ללא מזגן ולפעמים נכנסו גם קרני שמש.

הבעיות בעבודה בשיטה כזו הן פשוטות: או שאתה מתקין מזגן ומפעיל אותו 24/7 (בעייתי אצלי, האזור שהם נמצאים הוא אזור פתוח) או שאתה סובל מהרעש של המאווררים שמנסים לקרר את השרת (גם אם ניצול המעבדים נע על אחוזים בודדים). היו לי מספיק לילות שהייתי צריך לישון עם דלת חדר השינה סגורה. אם אין לך UPS (אני בכוונה לא עובד עם UPS, פרטים על כך בפוסט קרוב) – המצב יותר גרוע אם השרתים לא נמצאים בחדר סגור וחלה הפסקת חשמל – ההפעלה מחדש של השרתים תפעיל את המאווררים למקסימום מהירות למשך מספר דקות, מה שירעיש את כל הבית.

מחשבים – בין אם דסקטופ ואם מדובר בשרתים, יכולים לפעול בלי שום בעיה גם אם בסביבתם הטמפרטורה נעה בין 30-36 מעלות צלזיוס. דווקא במערכות דסקטופ ניתן לבנות את עקומת ה-RPM של המאווררים כך שיפעלו יותר לאט או יותר מהר בטמפרטורות מסויימות (פונקציה זו קיימת בתצורה סופר-בסיסית בשרתים תחת שמות כמו ECO, Silence וכו' אך מבלי להגדיר/לשנות מספרים).

ולהלן תובנותיי:

  • כל עוד מדובר במכונה שלא יבוצע לה Overclock ואין בה כרטיסי GPU, אפשר יהיה להרכיב לה 3-4 מאווררים (2-3 מקדימה בתצורת PULL, מאוורר מאחורה בתצורת PUSH), יחד עם המאוורר שמגיע עם המעבד – מכונה כזו לא צריכה מיזוג או תנאים מיוחדים (יש לי 2 מכונות דסקטופ כאלו שעובדות כך כבר 6 שנים).
  • מתוך הנחה (ולאחר בדיקות) שניצול ה-CPU אינו עובר את ה-60-70% – אפשר להתקין פתרון קירור של Noctua מסידרת ה-Low Profile (כל עוד יש את האיוורור שציינתי לעיל), כך שהמכונה תהיה שקטה גם בקיץ.
  • במידה ובונים מכונה ורוצים עליה שליטה מרחוק עוד ברמת הכיבוי/הפעלה – מומלץ לרכוש לוחות אם עם IPMI. במקרה של אינטל – קשה מאוד למצוא לוחות כאלו שמקבלים מעבדי דסקטופ, ומעבדי Xeon הם יקרים ולכן ניתן לוחות אם שתומכים במעבדי Xeon ישנים יותר (אני ממליץ E5 V2 ומעלה) או שניתן לרכוש לוח כזה עבור מעבד Ryzen מודרני.
  • שרתים מוכנים – ישן, אך לא ישן מדי: מאוד מפתה לרכוש שרת ישן בן 6-7 שנים בכמה מאות או ב-1000-1500 שקל כשכמעט הכל כלול (מעבדים, זכרון, רשת – אין דיסקים), אולם לא ניתן בשרתים כאלו להוסיף ציוד כמו SSD NVME, כרטיסי רשת מרובי כניסות וכו', וכמו כן מבחינת ביצועים – מעבד דסקטופ מודרני זול "בועט" בכל Xeon דור ראשון או שני (כשמדובר על אותה כמות ליבות ולפעמים כשב-Xeon יש כמות ליבות כפולה). ראו, אגב, הערותיי למעלה אם אתם חושבים להקים "LAB" שבעצם מבוסס על מכונה אחת.
  • אם אין לך בעיה שהמערכת לא תעבוד זולת שרותים בסיסיים בהפסקת חשמל ושכל המידע שלך בשרת האחסון לא יזוק כתוצאה מהפסקת החשמל – לא חייבים UPS. פוסט ופרטים על כך – בקרוב.
  • אפשר לבנות שרתים שקטים גם בתצורת 2U. וידאו ופרטים על כך – בקרוב.

הקיץ הזה אני אצטרך כפי הנראה (בהתאם לפרויקטים שיכנסו) מספר שרתים, שרת ה-ZFS העיקרי שלי יוחלף למשהו הרבה יותר מאסיבי (320 ג'יגה זכרון, 20 דיסקים קשיחים, Optane SSD ו-2 מעבדי Xeon וכנראה תקשורת במהירות 40 ג'יגה) ותהיה גם מערכת ניהול חכמה למקרים של הפסקת חשמל והפעלת שרתים עם שרותים בסיסיים שיפעלו ללא תלות בחשמל רציף. הכל יוקלט בוידאו ויפורסם ביוטיוב, פוסטים חדשים יופיעו בנידון וגם הקוד לניהול ישוחרר באופן חופשי ב-GitHub. אתם מוזמנים להירשם לבלוג (או לעקוב אחר הפייסבוק שלי או ערוץ הטוויטר שלי), ואני אשמח לקרוא את תגובתכם.

Exit mobile version