קטגוריה: חוות שרתים

האם כדאי לארח שרת ציבורי בתשתית ה-Lab שלנו?

סביר להניח שהתשובה לכותרת הפוסט זה תהיה מאנשים רבים: ״חס ושלום!״, במיוחד לאנשים שמבינים בתשתיות, מערכות הפעלה, אבטחה וכו׳

אבל לפני הכל, הנה קליפ קצר (2 דקות) מדוע חשבתי על העניין:

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

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

אז איך אפשר להימנע מהעניין, ועדיין להקים מכונה וירטואלית שתפנה לציבור, וגם לשמור על אבטחה כך שלא כל האקר יפרוץ לך לבית ויגרום נזק משמעותי? להלן מספר צעדים, חלקם כלליים וחלקם ספציפיים לתשתית (למען פוסט זה, אני מדברת על שימוש ב-Proxmox גירסאות 8/9, ומערכת הפעלה לינוקסית ב-VM, לא חשוב איזו הפצה)

נתחיל בדברים הכלליים:

  • ראשית, אנחנו לא נאפשר שום גישה ישירה ל-VM. כל הגישה לאתר בשרת תתבצע דרך שרותי tunnels שונים שנבחר: Cloudflare Tunnels, Tailscale funnel ואחרים, מה שאומר שאם מישהו גולש אל האתר שלך מבחוץ, הוא קודם כל נבדק לפני שהוא מגיע. זה לא מונע בוטים ודברים אחרים, אבל לכך נתייחס בהמשך
  • אנחנו לא נצטרך כתובת IP סטטית. ה-Tunnels חוסכים לנו גם הקמה ושימוש ב-Dyndns וגם מייתרים את הצורך בשימוש IP סטטי (אנחנו נגדיר בדומיין את ה-tunnel במקום זאת).
  • אנחנו נוודא שכמה שיותר דברים יצאו ״סטטיים״ (כמו פוסטים, עמודים) כך שמערכות Cache ינגישו אותם במקום לפנות שוב ושוב לשרת שלנו. כנ״ל לגבי תכנים כמו וידאו או אודיו: אם אנחנו לא יכולים לארח אותם באתרים ציבוריים (יוטיוב וכו׳), אנחנו יכולים להשתמש בשרותים זולים כמו R2 של Cloudflare לאירוח התכנים (מחיר: $0.015 סנט לכל ג׳יגה מעבר ל-10 ג׳יגה הראשונים שניתנים בחינם, ואין עלויות שידור המידע. כך לדוגמא הקליפ למעלה מגיע משרות זה)
  • להקשחה ולמניעת בוטים שונים, נוכל להשתמש בשרותי ה-WAF של cloudflare – על כך בהמשך.

מכאן נעבור לחלק הוירטואליזציה:

  • הדבר הראשון שנעשה הוא להקים VM רגיל, עם מערכת הפעלה שנרצה, עם כל התוכנות, העדכונים וההגדרות שנצטרך, בדיוק כמו כל VM שתקימו אצל ספק ענן ונוודא שהכל פעיל.
  • לאחר מכן נגדיר בוירטואליזציה Bridge. ה-Bridge יהיה עם כתובת IP יחודית (לשם הדוגמא בפוסט: 192.168.10.1/24) נקרא לגשר הזה vmbr2. חשוב לזכור לא לחבר אותו לשום כרטיס או פורט פיזי.
  • את ה-VM שהקמנו נכבה ונחליף בהגדרות הרשת שלה שהמכונה תהיה מחוברת אך ורק ל-vmbr2.
  • נפעיל את ה-VM ונגדיר את כתובת ה-VM לכתובת לדוגמא 192.168.10.10 עם subnet של 255.255.255.0 ו-GW של 192.168.10.1. מבחינת DNS נשים 1.1.1.1. נוודא שאנחנו יכולים לבצע ping אל ה-bridge (כלומר: 192.168.10.1). כרגע, שום נסיון לתקשר החוצה לעולם או לכל מקום אחר מעבר ל-bridge – לא יצלח.
  • אנחנו נשתמש ב-Proxmox לשרותי ניתוב. הדבר הראשון שנעשה זה להפעיל IP Forward, כך שהוא ידע לנתב את התעבורה. אנחנו גם נגדיר דרך iptables לזרוק כל פאקט שמגיע מה-lan שלנו (נניח בדוגמא זו שה-LAN שלכם הוא 192.168.0/24) אך כן להעביר אלינו ומאיתנו פאקטים לאינטרנט.
  • מכיוון שאת הרוב נצטרך להגדיר ידנית, הנה בלוק קוד לדוגמא שאמור לשבת בתוך קובץ etc/networking/interfaces/ ב-proxmox:
auto vmbr2
iface vmbr2 inet static
address 192.168.10.1/24
bridge-ports none
bridge-stp off
bridge-fd 0
     post-up echo 1 > /proc/sys/net/ipv4/ip_forward
post-up iptables -A FORWARD -i vmbr2 -d 192.168.0.0/24 -j DROP
     post-up iptables -t nat -A POSTROUTING -s 192.168.10.0/24 -o vmbr0 -j MASQUERADE
post-down iptables -D FORWARD -i vmbr2 -d 192.168.0.0/24 -j DROP
     post-down iptables -t nat -D POSTROUTING -s 192.168.10.0/24 -o vmbr0 -j MASQUERADE

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

  • עכשיו ה-VM יוכל לגשת לרשת האינטרנט אך לא ל-LANֿ, מה שאומר שאין לנו דרך לעשות SSH או כל תקשורת רגילה דרך ה-LAN ל-VM (רמז: אל תנסו להגדיר spice כאמצעי גישה למכונה, זה יתקע). איך נבצע בעצם גישה? דרך גישה מוצפנת כמו zero tier או tailscale שנתקין על ה-VM. לאחר מכן נכנס אל ה-VM ונראה אם אפשר דרך ה-tailscale לגלוש אל האתר/פלטפורמה ב-VM עם כתובת IP של tailscale (או פשוט שם). הצלחנו? מעולה, נמשיך לשלב הבא.
  • ניכנס לממשק cloudflare ונגדיר tunnel חדש. חשוב שנגדיר את ה-tunnel אל דומיין מסויים שרכשנו ורשמנו ב-cloudflare (ודרכו ננגיש את האתר לציבור). אם הגדרנו הכל כשורה, נוכל להיכנס דרך הדומיין אל האתר שלנו.

זהו. מעתה, כל גישה לאתר עצמו יכולה להתבצע אך ורק דרך ה-tunnels (אל תשכח להסיר כל הגדרת dynamic DNS מאותו דומיין), ולא ניתן להיכנס אליו דרך SSH

נקודה חשובה: יש צורך בשינוי הגדרות ב-virtualhost של שרת ה-web שלכם כדי שיכיר בכך שאתם משתמשים ב-cloudflare tunnels כך שתוכלו לראות את ה-IP האמיתיים והארצות שמגיעים אליכם. בלי השינוי, כל מה שתראו ב-לוגים זה 127.0.0.1.

סיימנו? זה כבר תלוי בכם. מכאן אפשר להגדיר WAF (בתוכנית החינמית זה מופעל אצלכם כברירת מחדל), אפשר להגדיר חוקי firewall ברמת ה-proxmox אם אתם רוצים לתת גישה לפורטים 80/443 אך ורק ל-cloudflare וכמובן לחסום פורטים אחרים, אבל תאורתית, מכיוון שהמכונה שלכם ״חבויה״, הדרך להיכנס אליה היא רק דרך ה-tunnels ואתם צריכים להגן טוב על הפלטפורמה או שרת ה-virtualhost שלכם.

להלן שאלות שבוודאי ישאלו ע״י הגולשים:

  • ״למה לא השתמשת ב-VLAN?״ התשובה לכך פשוטה: בלא מעט מקרים למשתמשים אין ציוד שמכיר ב-VLAN רמה 3, או שהם לא מכירים איך להשתמש, ובכל מקרה שימוש ב-bridge ״יתום״ יתן פחות או יותר את אותה פונקציה של הפרדה.
  • ״ספקי אינטרנט יכולים לחסום תעבורה או שהתעבורה יכולה להיות איטית, ולכן פתרון כזה אינו כדאי״. נכון, אבל שוב, כשהכל נמצא ב-cache רוחב הפס שנשתמש, הוא קטן מאוד, ושיחת וידאו לוקחת הרבה יותר רוחב פס מגישה לאתר סטטי ברובו.
  • ״מה שהצעת לא מספיק מוגן״. יכול להיות, אבל מה שנחשב ״מוגן״ למישהו אחד, יכול להיחשב ״בלתי מספיק״ למישהו אחר. אין גבול לכך
  • ״לא הגדרת שום דבר מבחינת תשתית הוירטואליזציה עצמה להגן עליה״. נכון, נסו לחשוב על כך – הדרך היחידה של פורץ היא להיכנס רק דרך ה-VM וגם אז רק דרך ה-web (אם הגדרת רק HTTP ב-tunnel), כך שגם אם הוא יקבל shell, אין לו דרך ״לדבר״ עם ה-lan כי אנחנו חוסמים זאת ברמה מעבר ל-VM. יש סיכון קטן של ״בריחה מה-VM״, אבל אז כבר מדובר בכשלי אבטחה בוירטואליזציה שמתוקנים די מהר בעדכונים השוטפים
  • ״ניתן להפיץ נוזקות ותולעים עם גישה כזו״. אפשר לעשות אותו גם דרך Hosting רגיל ב-vm שמוכרים לך

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

אשמח לשמוע את דעתכם.

התקלה הגדולה ב-AWS וביזור אמיתי של ענן

אתמול התרחשה תקלה מאוד משמעותית ב-AWS, תקלה שהשביתה אתרים רבים, כולל אתרים גדולים וידועים שהתארחו על AWS, והפעם – גם אתרים שגיבשו ומימשו תהליך שרידות של Multi Zone או Multi Region, מצאו את עצמם סובלים בדיוק כמו אחרים.

לשמחתינו, בניגוד לכל מיני ספקים ישראליים (אינני מדברת על הנציגויות של ספקי הענן העולמיים) – אמזון שיתפה מידע לגבי התקלה: מתברר כי קריאות API ל-DynamoDB הגדול שמנהל פנימית את כל השרותים של אמזון ונמצא ב-US-EAST-1 – לא קיבל ולא שלח תשובות לקריאות עקב תקלות DNS (לאלו המעוניינים,הנה הסבר יותר מפורט של ג׳מיני לתקלה – בעברית)

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

תקלה כזו מראה כמה חשוב לכל אתר שצריך להיות באויר בכל זמן – לחשוב ביתר רצינות על פתרונות המבוססים Multi Cloud, כך שאם נופל שרות זה או אחר אצל ספק ענן A, המערכת תעבור אוטומטית לספק שרותים מספק ענן B, וכיום פלטפורמות כמו Terraform מסייעים מאוד להקים פתרונות כאלו.

כמה מילים על הרכישות של OpenAI

לאחרונה אנחנו נתקלים ביותר ויותר חדשות לגבי OpenAI והרכישות המאסיביות שלה. כאן החברה עושה עיסקה סיבובית עם Nvidia לגבי רכישת ציוד בגודל ״10 ג׳יגהוואט״ (איפה הימים שפשוט היו סופרים כרטיסים או מערכות..)  – ובמקביל Nvidia משקיעה ב-OpenAI סכום ״צנוע״ של 100 מיליארד דולר..

אבל זו כמובן לא העיסקה היחידה. קדמה לה עיסקה של OpenAI עם ברודקום, בסכום של 10 מיליארד דולר. במסגרת עיסקה זו, ברודקום תיצור שבב עבור OpenAI (כלומר ASIC) שישמש, כנראה, לצרכי Inference.. או משהו. החברות לא הרחיבו על כך.

אז השבבים של Nvidia ישמשו לאימון (training), השבבים של AMD ש-OpenAI רכשה ורוכשת ישמשו לצרכי Inference והשבבים מ-ברודקום יחליפו בהדרגה את הדור הנוכחי והישן יותר מ-Nvidia…?

לא בדיוק..

רק לפני מס׳ ימים הכריזו AMD ו-OpenAI כי האחרונה תרכוש מהראשונה כמות המוערכת ב-״6 ג׳יגהוואט״ של GPU מהסוג החדש ש-AMD תוציא בשנה הבאה (ה-MI450). ב-OpenAI, כפי שציינתי, משתמשים בשבבים של AMD לצרכי Inference, אך מה שאינו מובן לי לגבי עיסקה זו – היא הצורך בה. אתם מזמינים ב-10 מיליארד דולר שבבי Custom, אז למה אתם צריכים את השבבים של AMD?

העניין נראה עוד יותר תמוה כשמבינים (ליתר דיוק .. מנסים להבין) את העסקאות הסיבוביות. במקרה עם Nvidia, חברת OpenAI אמנם משלמת על הכרטיסים, אבל היא מקבלת בחזרה כסף בצורת השקעה מצד Nvidia, כך שזה יוצא מכיס אחד, אבל נכנס מהכיס השני (נכנס פי 10, ליתר דיוק) בכפוף לעמידה ביעדים. במקרה עם AMD זה נעשה יותר מורכב: OpenAI תשלם ל-AMD על הציוד, אבל היא תקבל לאחר מילוי ההזמנה הראשונה (של 1 ג׳יגהוואט) ״צו רכישה״ (תרגום של ג׳מיני) של מניות במחיר של 1 פני, עד 160 מיליון מניות. מניות אלו יהיו ניתנות למימוש רק אם החברות תעמודנה באבני דרך להקמת הפרויקט, ורק אם המניה תעמוד ביעדי מחיר ספציפיים, ואם מחיר המניה יגיע ל-600 דולר, OpenAI יוכלו לממש את כל החבילה.

אין ספק שהתנאים הללו הם תנאים מעולים ל-OpenAI, אבל כאן מגיעה הבעיה היותר גדולה: הקמת חוות השרתים. כשמדובר בחוות של 1 ג׳יגהוואט ומעלה (להלן קישור לקליפ מהערוץ של
Anastasi In Tech על הקמת חוות השרתים של xAI) – מדובר באתגר עצום שאינו קל לפתרון, והבעיה פחות קשורה לרכישת וקבלת GPU אלא דברים שקשה להשיג ולהקים, כמו חשמל, קירור ועוד, וכשמדברים על מעבר ל-1 ג׳יגהוואט, הבעיה מכפילה את עצמה ומעבר.

כך שבסופו של יום, לא בטוח ש-OpenAI תצליח לעמוד באתגרים הללו. החברה מזמינה ציוד על ימין ועל שמאל, ובנוסף חותמת עם אורקל לאספקת שרות בשווי מוערך של 300 מיליארד דולר ל-5 השנים הקרובות (ואורקל תצטרך להלוות 100 מיליארד דולר בפריסה של 4 שנים רק כדי להקים את אותן חוות ולרכוש את הציוד), אבל גם כאן, הסיכון הוא עצום.

האם יהיה כאן מה שהגשש החיוור קרא ״40 קומות באוויר, 20 קומות באדמה״? כלומר .. בועה שתגרום לחברות רבות להינזק?

ימים יגידו..