.png)
.png)
השבוע הפינה בחסות VMware Cloud Provider Program
מתחילים את השבוע עם סיכום השבוע החולף בעננים. כמו תמיד כל מי שמעוניין לתרום או לציין נושא חשוב שפספסנו, מוזמן לפנות אלינו: support@israelclouds.com
סיכום השבוע בתחום מחשוב ענן בערוצי IsraelClouds ובעולם:
דבר העורך
פיצ'ר חדש של LinkedIn מציג את כוחה של מיקרוסופט. ענקית הענן אשר רכשה את לינקדאין ב- 2016 מנצלת את יכולותיה כדי להוסיף פיצ'ר שימושי לרשת החברתית: לינקדאין תתרגם את התוכן של כל דף לאחת מעשרות שפות אחרות בלחיצת כפתור. יכולת זו חשובה במיוחד מכיוון שהיא משפיעה על 500 מיליון המשתמשים של הרשת, אשר רובם אינם דוברי אנגלית כשפת אם.
השימוש של לינקדאין ב-Azure מהווה ציון דרך משמעותי עבור מיקרוסופט, ומוכיח הלכה למעשה שמדובר בפתרון מחשוב מוצלח עבור עסקים המעוניינים להתעסק יותר בפעילויות הליבה שלהם, ופחות בתחזוקה שוטפת של הענן.
מה עושים כשהרובוטים של גוגל מחליטים לחסל לך את העסק?
בעל עסק פרסם השבוע בפלטפורמת הבלוגים מדיום תרחיש מעניין שקרה בחברתו: מערכת ניטור של Google Cloud שעובדת עבור מפעלי ייצור אנרגיה בעסק שלו הושעתה בהמלצת הרובוטים של גוגל, והעסק קיבל 72 שעות בלבד להגיב - כלומר לשלוח אימות באמצעות תעודת זהות של בעל החשבון ב- GCP, אחרת יהרסו הקוד העסקי והנתונים.
במקרה זה, המנהל הגיב מהר וזמן ההשבתה עמד על שעה אחת בלבד, אבל מה אם בעל החשבון (במקרה זה, סמנכ"ל הכספים) לא היה זמין? תגובות מוגזמות כמו זו הביאו לכך שלאחרונה מתלהטים דיונים רבים בנושא התמיכה של גוגל, ברשתות כמו Reddit ו- Hacker News.
Autodesk חוברת ל- AWS כדי לספק שירות ענן חינמי. העתיד של (CAD Computer-Aided Design) ותוכנות סימולציה נוספות צפוי בעתיד להיות מבוסס במידה רבה על הענן, אבל האם הציבור תומך ברעיון של יישומי תכנון הנדסי מבוססי ענן?
כדי לעודד את העניין הציבורי בתוכנות לתכנון הנדסי כגון CAD / CAE חברה Autodesk ל-AWS, כדי לספק שירותי ענן בחינם עבור משתמשי תוכנות עיצוב ממוחשבות. המהלך נועד לקחת תעשיות Low-Tech כמו הנדסת בניין, הנדסת מכונות וייצור, ולהציג להן את היתרונות הגדולים הטמונים בענן ואת האפשרויות העסקיות שמחשוב ענן מאפשר.
עדכוני עננים:
Azure
http://bit.ly/microsoft_azure_updates
AWS
http://bit.ly/Amazon_AWS_updates
GCP
http://bit.ly/Google_GCP_updates
שאלות מעניינות שנשאלו ונענו ב:
קבוצת הפייסבוק וואטסאפ של קהילת מחשוב הענן בישראל
שאלות ותשובות מהאקו-סיסטם שלנו השבוע:
Azure
1. שאלה
האם מישהו יודע איך עוצרים Service Fabric? אני מעוניין לעצור את ה-Nodes אבל לא למחוק את ה-Cluster. כיצד עושים זאת?
תשובה
האם בחנת את האפשרות להשתמש בפקודה של Stop-AzureRmVmss ככה אפשר להוריד את ה-Nodes? בנוסף, אפשר להשתמש בזה: http://bit.ly/azureservicefabricps
2. שאלה
האם יש דרך לגבות באמצעות Azure Backup Agent כונן ברשת/תקייה ברשת? עד כה לא מצאתי אופציה כזו.
תשובה
אתה יכול לעבוד עם Azure Files ולהגדיר קובץ בענן כתיקיית רשת וירטואלית. בשלב הבא אתה יכול להשתמש בתקיית רשת זו מכל מחשב בענן או מחשב מקומי על מנת לגבות קבצים או כוננים שלמים.
3. שאלה
שאלה בנושא Azure DevTest Lab:
יש לי VM עם ווינדוס 10 ועליו מותקנת המערכת של החברה, אני מנסה ליצור מעבדה עם כמה שיותר מחשבים זהים למחשב הקיים, אבל נכשל ביצירה של המכונות.
שיטות שניסיתי עד עכשיו:
1. לעשות Sysprep עם Genralize למכונה, ואז ליצור את ה- Image דרך Azure Portal ולעלות ממנו.
2. לייצר Image וש- Azure יעשו את ה- Sysprep - לא עבד בכלל, Image לא נוצר גם אחרי 3 ימים.
3. ליצור פורמולה ולעלות ממנה - לא עבד, כל המכונות נכשלו.
4. דרך Azure Resource Manager לעשות Sysprep עם Genralize למכונה, אז ליצור את ה- Image ולעלות ממנו.
השתמשתי ב-Base בווינדוס 10 של Azure וב- VM size בחרתי ב (Standard B2s (2 cores, 4 GB memory
*לא השתמשתי ב- Azure Power Shell ואני מעדיפה שלא לעשות זאת.
תשובה
ה-Sysprep נופל כי Windows 10 ביצע “הטמעה" לכל מיני אפליקציות מה- Store.
יש להסיר את האפליקציות מכל המשתמשים (לא רק המשתמש שעושה את ה-Sysprep) ואז לבצע Sysprep.
* בלוג של ה-Sysprep את תראי על מה הוא נופל (כל פעם אחד).
http://bit.ly/sysprep-windows-10
4. שאלה
האם זה אפשרי להעביר מכונות וירטואליות מ- Subscription של משתמש X ל-Subscritpion של משתמש Y
כאשר הם לא באותה Directory?
תשובה
איך להעביר (להעתיק) מכונה עם ManagedDisk לחשבון אחר
http://bit.ly/move-vm-manageddisk
AWS
1. שאלה
אני מחפש רפרנס לארכיטקטורת הייבריד שבקצה אחד יהיו לי EC2 ובקצה השני Data Center גדול.
התקשורת בין 2 הנקודות תיהיה כבדה וצריכה להיות מהירה (מעל ל-10 ג’יגה), אבל היא לא תגיע ל-10 ג’יגה 24/7 וברוב שעות היום תיהיה נמוכה יותר.
תכננתי משהו ראשוני ובסיסי עם Direct Connect, אבל אשמח לשמוע אם יש דרכים יעילות וזולות יותר לעשות את החיבור הזה בין On-Prem ל- Public Cloud
תשובה
למשימות קטנות לא צריך להחזיק צוות קרוב, שווה לשלם 200$ בשביל לא לשלוח טכנאי או לטוס לשם בעצמך אבל למשימות גדולות אני ממליץ לך לשלוח צוות או לשכור צוות מקומי מחוץ לחווה. התמחור השעתי שלהם מטורף
אמזון פורסים עד ה- Meet-Me-Room של אקוויניקס, אתה שם הציוד שלך בארון \ קייג' באותה החווה ושוכר מאקוויניקס Cross Connect מהסוויץ' בארון שלך לסוויץ' של AWS Direct Connect.
אתה משלם לאמזון (במקרה שלך 1600 דולר בחודש עבור חיבור 10 גיגה) ומשלם לאקוויניקס על הקישור שהם מריצים ומתחזקים לך בין הארון שלך לבין ה-MMR.
2. שאלה
האם קיימת אפשרות ב-AWS להגיד ל-LB שיאזין על טווח של PORTS ואז יעביר ל-Target Group לפי ה-PORT שיתקבל בבקשה? לדוגמא, אם פניתי בטווח PORTS של 3000-4000 אז זה יעבור ל-Target group ספציפי.
תשובה
ה- ALB עובד ב- Layer 7. העובדה שהוא מאפשר לקבל HTTP או HTTPS בפורטים שונים מ"הסטנדרטים" לא אומרת שהוא מנתב ב- Layer 4.
3. שאלה
אני כותב אפליקציית nodejs שמקבלת כ- 10000 קריאות בשניה (ממס' אפליקציות צד ג' ובסדר גודל של מיליארד בקשות ביום) עם מידע שאני רוצה לשמור.
המידע שאני רוצה לשמור מכיל כ- 10-15 שדות, כמו מיקום (lon, lat), מזהים ושדות טקסט נוספים.
אין לקוחות, מדובר בכלי פנימי, ואנחנו רוצים לעבוד ישירות מול ה- DB.
אני רוצה שתהיה לי אפשרות מהירה (זמן הגיוני, עד מס' דק') לתשאל את המידע של השבוע האחרון (סדר גודל), ותהיה לי אפשרות נוספת (לא חייבת להיות מהירה) לתשאל את המסד הכולל.
בנוסף, אני רוצה לבחור בכלי שלא ידרוש ממני התעסקות מתמדת בתחזוקה.
ההתלבטות שלי:
-איזה סוג DB לקחת עבור המידע המהיר \ המידע הלא מהיר?
-האם המידע צריך לעבור נרמול? (ORC, פרקט וכו') אם כן, זה מגביל אותי בבחירת ה- DB.
-קוסט אפקטיביות של הפתרון (מדובר פה בסדר גודל של עשרות\מאות טרות לאחר מס' חודשים)
-מבחינת ה- Node Instance: בגלל שמדובר בקצב קבוע וידוע מראש, האם עדיף לקחת Single Instance מספיק גדול או לפצל מאחורי LB?
תשובה
שים לב שהיום כפופים תקנות ה- GDPR אז אי אפשר לשמור, וחייבים לאפשר יכולת מחיקה עבור משתמשים אירופאים (ממליץ לחשוב על פתרון כולל): EMAIL, IP מעל 3 אוקטבות, מיקומי LOC CI, ספרה אחת אחרי הנקודה של LAT LONG, ואולי עוד כל מיני, צריך להתייעץ עם עו"ד.
באופן כללי זה רעיון טוב לשמור את המידע בפרקט או ORC ב-S3 במודל PARTITION ויתושאל ב-ATHENA, למרות שמודל זה מתאים בעיקר לצרכי OFFLINE ולא REALTIME (שעה עיכוב נגיד). שים לב שהמודלים הללו נכונים בעיקר אם מדובר בערכים חוזרים וב-TIME SERIES.
המרה יכולה להתבצע במגוון כלים: אפשר LAMBDA שיריץ EMR או ELB שירוץ מאחורה JAVA / SCALA עם SPARK, אולי שילוב של האופציות (לשמור כJSON/AVRO בשרתים ופעם בשעה לפרסס), רוב הסיכויים ש- ELB יעלה פחות אבל ידרוש יותר תשומת לב ולאט לאט יצרוך גם מעבר ל- AUTO SCALING כמו טיב כל שרתי STATISTIC ANALYTIC וכדומה.
אנחנו מריצים את ההמרה תחת APACHE DRILL בהיבט של חיסכון אבל זה לאו דווקא הפתרון הנכון לך. רצוי שכל תהליך המרה ירוץ במינימום כל שעה, כדי לתת היבט של קימפרוס אופטימלי. השאלה אם צריך היבט של ניטור REALTIME בנוסף ואז אפשר ללכת על בנוסף KAFKA/KINESIS או ELASTICSEARCH לתחקור לוגים ולתת מדדים מינימלים לעלייה וירידה.
אצלנו לדוגמא אנחנו מסתפקים באגרגציות חכמות של ACCESS LOGS ברמת כל 5 דקות (כמו שנותן הELB) שנשמרים ב- Redshift (בגדלים הללו אפשר גם DB פשוט אחר פשוט זה מה שיש גם ככה בארגון), ועוד המרה יומית של כל הדאטה לפרקט ותשאול דרך ATHENA (יותר משמש אנליסטים שחשוב להם עולם היוזר ופחות סטטיסטיקות יבשות). יש לנו בנוסף כל מיני קאונטרים שמתעדכנים בקסנדרה אבל מחוץ לקונטקסט הזה.
מבחינת עלויות, רצוי ששרתי ה-ELB של ה- STATISTIC יהיו SPOTים וכמובן מאחורי ELB, אם מדובר בצרכי ROUTING שונים אולי כדאי אפילו לשקול ALB. אם אתה רק צריך לתשאל את השבוע האחרון במהירות עדיף להגדיר ב-S3 LIFECYCLE שילך ל-GLACIER. מה שגדול- 10 ימים (בערך) או לעשות את זה יזום, מדובר על חסכון די גדול.
מקווים שנהניתם.