✕ סגור 
צור קשר
תודה על ההתעניינות .

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

ביצועי Network ושיקולים במעבר ל-GCP

מתן גרביץ
|
Apr 18, 2019
alt="blogs"
alt="blogs"
alt="blogs"
Events
Event
title="Google"

ידע קודם רצוי: ידע והבנה בסיסיים בלינוקס ורשתות

לקחתם החלטה והחלטתם להעביר את ה-Workloads שלכם מ"הברזלים" אל הענן הציבורי - שינוי מבורך.

אך לפני כן, יש כמה דברים שרצוי לדעת:

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

- להבין מה הענן אותו בחרתם מציע והאם הוא הבחירה הנכונה עבורכם?

- אילו מה-Workloads  שלכם יכולים לעבור בקלות לענן? או בסלנג הטכני, לאיזה מה-Workloads אפשר לעשות: "Lift & Shift"?

- להבין את ה-Infrastructure וההגבלות שקיימות בענן ולא קיימות בסביבת ה-BARE METAL שלכם.
לדוגמא: אתם זקוקים לדיסק מאוד מהיר בנפח לא גדול במיוחד שישמש עבור קבצי לוג מהאפליקציה שלכם שנכתבים, מועתקים למקום אחר ולבסוף נמחקים בקצב מהיר. האם נפח דיסק קטן ייתן לכם מספיק IOP/s ו-throughput בכדי לעמוד בקצב, ובאיזה סוג דיסק כדאי לבחור?

Compute Engine


Compute Engine, או בשמו המקוצר "CE" הוא התשובה של GCP ל-2EC של AWS.
במאמר זה בחרתי להתמקד בצד ה-Network, שהוא חלק בלתי נפרד מכמעט כל Workload שאני מכיר אך לא תמיד נותנים לו את תשומת הלב הראויה, ואני מקווה שלאחר הקריאה והרצת הבדיקה בסביבה שלכם, תצליחו לשפר לפחות במעט את העלות מול התועלת.


* שימו לב שתמחור טרנזקציות (תנועות) הרשת שלכם יכול להיות מאוד יקר כשלא מודעים למחירים ולצורת התמחור, לכן אינני לוקח אחריות כלשהיא ומעודד אתכם לקרוא את המסמכים הרשמיים, להבין ולתכנן כל בדיקה בהתאם לתקציב שברשותכם

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

:Zone מייצג את האזור בו נקים את ה-Resources שלנו ברזולוציה מאוד ממוקדת.
בכל Zone נמצא את שירותי ה-GCP. המכונות שנקים, ירוצו גם הן בתוך Zone ספציפי.

Region: הגדרה כוללת לאזור גיאוגרפי שמקבץ תחתיו Zone אחד או יותר שנמצאים תחת אותו אזור גיאוגרפי.

Virtual Private Cloud: מגדיר את סביבת הרשת שלנו. בתוך ה-VPC נגדיר את הרשתות וה-Workloads שלנו.
VPC: משאב גלובלי המתקיים ב-Region אחד או יותר ומאפשר לנו גישה ברשת פרטית
בין Regions שונים בעולם – ז"א שלא דרך האינטרנט הציבורי.

Subnet: מייצג טווח כתובות שאנחנו נרצה להגדיר בתוך ה-VPC שלנו.
נוכל להקים סאבנט פנימי ו/או חיצוני בהתאם לדרישות שלנו, וכל אחד מהם יכול להיות משוייך ל-Zone אחד בלבד.

Compute Engine: מכונה וירטואלית שמאפשרת התקנה של רוב הפצות הלינוקס, או לחילופין חלונות של מייקרוסופט.

Virtual Private Cloud: מגדיר את הסביבה שלנו. בתוך ה-VPC נגדיר את הרשתות שלנו וה-Workloads שלנו.


עוד כמה מילים על Compute-Engines

לבדיקה הנוכחית אנחנו נבחר מכונה מסוג Standard או Custom, אולם חשוב שתדעו
ש-GCP מציע מספר משפחות של CEs ל-Workloads שונים.
אם החלטתם להעביר את שרת הווב שלכם אולי תסתפקו במשפחת ה-Standard, אבל
במידה ויש לכם Workload שרץ In-memory, כמו Spark (ואתם לא רוצים לעבור לשירות מנוהל), או שאולי יש לכם אפליקציה שמקודדת וידאו בזמן אמת (JITP) ומעמיסה על המעבד – כנראה שתוכלו להפיק תועלת ממשפחה מאוד ספציפית של Compute-Engine.


(https://cloud.google.com/blog/products/compute/introducing-compute-and-memory-optimized-vms-for-google-compute-engine)


מה אנחנו בעצם הולכים לבצע

1. נתחיל לתכנן את הבדיקות שלנו ונפצל את הרשת לרשתות פנימיות וחיצוניות – להן עלויות שונות
2. נוודא שאנחנו בוחרים ב-Compute Engine שתומך בנפחים שאנו דורשים
3. נבחר ב-Region הקרוב לנקודות הקצה שלנו, אותם אנחנו מתכננים לשרת (לקוחות)
4. נתקין כלי סינתטי לייצור תעבורה על לפחות 2 שרתים: אחד יהיה צד השרת והשני צד הלקוח
5. נתקין כלים לניטור הרשת וה-Compute engines שלנו, על מנת שנפיק את המירב מכל בדיקה
6. נעבור על תוצאות הבדיקה, נאתר בעיות או חסמים פוטנציאלים – וננסה לשפר אותם
מתחילים:
אנו נרצה ליצור 2 Compute engines, אחד עבור השרת ואחד עבור הלקוח.
את שניהם אצור עם 32 ליבות ואבחר בטכנולוגיית Skylake העדכנית של אינטל
וב-Region/Zone שרלוונטיים עבורי.
לטובת הכלל אחלוק את השיקולים שלי כדי שהבחירה תהיה מובנת יותר:

1. קרבה גיאוגרפית לישראל – מכיוון שהלקוחות שלי יהיו מישראל
2. עלות סבירה (משתנה בין האזורים, אם כי היא זניחה)
3.  Zone שיכול לספק אינסטנסים עם 32vCPUs

בנוסף בחרתי ב-Default VPC לצורך הבדיקה

איך זה נראה בפועל


יצירת אינסטנס עבור הקליינט ועבור הסרבר:

ובחירת המעבד:


* שימו לב שבהתאם ל-Region  שבחרתם, ייתכן ו-Skylake לא יהיה זמין.
(https://cloud.google.com/compute/docs/cpu-platforms)

לאחר שיצרנו בהצלחה 2 אינסטנסים, נוודא שהם עלו בצורה תקינה ויש להם 2 כתובות IP חיצונית ופנימית:

IPERF3


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

NMON


.UDP וגם TCP הוא הכלי הסינטטי איתו נריץ בדיקות. הכלי מסוגל לייצר תעבורת
הכלי דורש לפחות 2 מכונות: אחד ירוץ כשרת והשני ירוץ כלקוח.


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

IPTRAF


כלי ותיק לניטור ביצועי הרשת. מאוד שימושי בבדיקות ביצועי רשת.

MTR


ומאפשר בין היתר לשמור את המידע ע"ג קבצים Ping ובין Tracerouteכלי יעיל שמשלב בין  
:yum / apt-getההתקנה יחסית פשוטה במידה ונשתמש ב-

yum install <package-name> -y
apt-get install <package-name> -y

לפני שנתחיל בבדיקה הסינטטית, נריץ מספר פקודות בסיסיות ונבחן את הפלט שלהן:

ifconfig
ethtool eth0
traceroute cnn.com
mtr cnn.com

האם שמתם לב להבדלים בין מערכת GCP לבין האינסטנס ב-BARE METAL?


חזרה לבדיקה הסינטטית שלנו

:IPERFלאחר שהתקנו את הכלים, נרים שרת  


iperf3 -s

ומהמכונה השנייה נדמה את הלקוח ונריץ את הבדיקה:


iperf3 -c <your-server-ip> -B0 -P <number-of-clients>


מה בעצם ביקשנו להריץ?


 ולהעביר את המקסימום מקצה לקצהTCPפנינו לשרת שמאזין בצד השני וביקשנו להריץ בדיקת  
man iperf3מידע על כל האפשרויות הזמינות אפשר לקבל דרך אם נריץ  

"SUMאת התוצאות של הבדיקה נקבל בסופה גם בצד השרת וגם בצד הלקוח בשורת ה"


מה למדנו מהבדיקה


הקמנו 2 מכונות שמריצות לינוקס ולמדנו להריץ בדיקת מהירות סינטטית בין שני שרתים.
את הבדיקה הפשוטה יחסית נוכל לפתח לסט בדיקות בין משאבים שנמצאים באזורים שונים, דרך
או הרשת הציבורית, על מנת לבדוק את ביצועי הרשת, חווית המשתמש ויציבות ה-VPN, Peering
וה-Workload שלנו.

ראינו גם את ההבדלים בין מערכות bare metal לבין הרשת ב-GCP:

- בהרצה של ETHTOOL לדוגמא, נראה מידע מצומצם על ה-ETH שלנו.
- 1460 MTU נכון לזמן כתיבת המאמר זו הגבלה קשיחה של התשתית, אולם יש לגוגל תוכניות
 עתידיות להציע גם 9000 MTU – Jumbo Frames.
- אם נריץ traceroute cnn.com לדוגמא, הפלט שנקבל יהיה מוסתר בכוכביות, לכן נעדיף להשתמש
 ב-MTR - My trace route.


מה מצפה לנו בעולם האמיתי


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

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

- נבחר באזור גיאוגרפי שקרוב למשתמשים שלנו כדי למנוע עיכובים שנוצרים מאיטיות ברשת

- נבחר בקפידה את גודל האינסטנסים שלנו: מספר הליבות במעבד שנבחר יקבע את המקסימום
 throughput שאליו נגיע

- ייתכן ונצטרך להגדיר פרמטרים נוספים, על מנת לשפר את הביצועים  
 ברמת מערכת ההפעלה. מדריך מקיף בנושא אפשר למצוא כאן והיכרות עם לינוקס היא הכרחית:  
 https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl

- CDN במידה ויש לנו קבצי מדיה או קבצים סטטיים, נרצה בוודאות לשקול את השימוש ב-CDN  
 שיוריד מאיתנו את העומס וישרת את הלקוחות שלנו מנקודה קרובה יותר, מה שיתבטא בטעינה
 מהירה יותר של אובייקטים.

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

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

בהצלחה!


לקריאה נוספת:

https://cloud.google.com/compute/docs/machine-types
https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations
https://cloud.google.com/compute/docs/cpu-platforms

https://cloud.google.com/vpc/

https://cloud.google.com/blog/products/gcp/5-steps-to-better-gcp-network-performance?hl=ml
https://cloud.google.com/blog/products/compute/introducing-compute-and-memory-optimized-vms-for-google-compute-engine

מאת: מתן גרביץ
matan.gr

ידע קודם רצוי: ידע והבנה בסיסיים בלינוקס ורשתות

לקחתם החלטה והחלטתם להעביר את ה-Workloads שלכם מ"הברזלים" אל הענן הציבורי - שינוי מבורך.

אך לפני כן, יש כמה דברים שרצוי לדעת:

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

- להבין מה הענן אותו בחרתם מציע והאם הוא הבחירה הנכונה עבורכם?

- אילו מה-Workloads  שלכם יכולים לעבור בקלות לענן? או בסלנג הטכני, לאיזה מה-Workloads אפשר לעשות: "Lift & Shift"?

- להבין את ה-Infrastructure וההגבלות שקיימות בענן ולא קיימות בסביבת ה-BARE METAL שלכם.
לדוגמא: אתם זקוקים לדיסק מאוד מהיר בנפח לא גדול במיוחד שישמש עבור קבצי לוג מהאפליקציה שלכם שנכתבים, מועתקים למקום אחר ולבסוף נמחקים בקצב מהיר. האם נפח דיסק קטן ייתן לכם מספיק IOP/s ו-throughput בכדי לעמוד בקצב, ובאיזה סוג דיסק כדאי לבחור?

Compute Engine


Compute Engine, או בשמו המקוצר "CE" הוא התשובה של GCP ל-2EC של AWS.
במאמר זה בחרתי להתמקד בצד ה-Network, שהוא חלק בלתי נפרד מכמעט כל Workload שאני מכיר אך לא תמיד נותנים לו את תשומת הלב הראויה, ואני מקווה שלאחר הקריאה והרצת הבדיקה בסביבה שלכם, תצליחו לשפר לפחות במעט את העלות מול התועלת.


* שימו לב שתמחור טרנזקציות (תנועות) הרשת שלכם יכול להיות מאוד יקר כשלא מודעים למחירים ולצורת התמחור, לכן אינני לוקח אחריות כלשהיא ומעודד אתכם לקרוא את המסמכים הרשמיים, להבין ולתכנן כל בדיקה בהתאם לתקציב שברשותכם

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

:Zone מייצג את האזור בו נקים את ה-Resources שלנו ברזולוציה מאוד ממוקדת.
בכל Zone נמצא את שירותי ה-GCP. המכונות שנקים, ירוצו גם הן בתוך Zone ספציפי.

Region: הגדרה כוללת לאזור גיאוגרפי שמקבץ תחתיו Zone אחד או יותר שנמצאים תחת אותו אזור גיאוגרפי.

Virtual Private Cloud: מגדיר את סביבת הרשת שלנו. בתוך ה-VPC נגדיר את הרשתות וה-Workloads שלנו.
VPC: משאב גלובלי המתקיים ב-Region אחד או יותר ומאפשר לנו גישה ברשת פרטית
בין Regions שונים בעולם – ז"א שלא דרך האינטרנט הציבורי.

Subnet: מייצג טווח כתובות שאנחנו נרצה להגדיר בתוך ה-VPC שלנו.
נוכל להקים סאבנט פנימי ו/או חיצוני בהתאם לדרישות שלנו, וכל אחד מהם יכול להיות משוייך ל-Zone אחד בלבד.

Compute Engine: מכונה וירטואלית שמאפשרת התקנה של רוב הפצות הלינוקס, או לחילופין חלונות של מייקרוסופט.

Virtual Private Cloud: מגדיר את הסביבה שלנו. בתוך ה-VPC נגדיר את הרשתות שלנו וה-Workloads שלנו.


עוד כמה מילים על Compute-Engines

לבדיקה הנוכחית אנחנו נבחר מכונה מסוג Standard או Custom, אולם חשוב שתדעו
ש-GCP מציע מספר משפחות של CEs ל-Workloads שונים.
אם החלטתם להעביר את שרת הווב שלכם אולי תסתפקו במשפחת ה-Standard, אבל
במידה ויש לכם Workload שרץ In-memory, כמו Spark (ואתם לא רוצים לעבור לשירות מנוהל), או שאולי יש לכם אפליקציה שמקודדת וידאו בזמן אמת (JITP) ומעמיסה על המעבד – כנראה שתוכלו להפיק תועלת ממשפחה מאוד ספציפית של Compute-Engine.


(https://cloud.google.com/blog/products/compute/introducing-compute-and-memory-optimized-vms-for-google-compute-engine)


מה אנחנו בעצם הולכים לבצע

1. נתחיל לתכנן את הבדיקות שלנו ונפצל את הרשת לרשתות פנימיות וחיצוניות – להן עלויות שונות
2. נוודא שאנחנו בוחרים ב-Compute Engine שתומך בנפחים שאנו דורשים
3. נבחר ב-Region הקרוב לנקודות הקצה שלנו, אותם אנחנו מתכננים לשרת (לקוחות)
4. נתקין כלי סינתטי לייצור תעבורה על לפחות 2 שרתים: אחד יהיה צד השרת והשני צד הלקוח
5. נתקין כלים לניטור הרשת וה-Compute engines שלנו, על מנת שנפיק את המירב מכל בדיקה
6. נעבור על תוצאות הבדיקה, נאתר בעיות או חסמים פוטנציאלים – וננסה לשפר אותם
מתחילים:
אנו נרצה ליצור 2 Compute engines, אחד עבור השרת ואחד עבור הלקוח.
את שניהם אצור עם 32 ליבות ואבחר בטכנולוגיית Skylake העדכנית של אינטל
וב-Region/Zone שרלוונטיים עבורי.
לטובת הכלל אחלוק את השיקולים שלי כדי שהבחירה תהיה מובנת יותר:

1. קרבה גיאוגרפית לישראל – מכיוון שהלקוחות שלי יהיו מישראל
2. עלות סבירה (משתנה בין האזורים, אם כי היא זניחה)
3.  Zone שיכול לספק אינסטנסים עם 32vCPUs

בנוסף בחרתי ב-Default VPC לצורך הבדיקה

איך זה נראה בפועל


יצירת אינסטנס עבור הקליינט ועבור הסרבר:

ובחירת המעבד:


* שימו לב שבהתאם ל-Region  שבחרתם, ייתכן ו-Skylake לא יהיה זמין.
(https://cloud.google.com/compute/docs/cpu-platforms)

לאחר שיצרנו בהצלחה 2 אינסטנסים, נוודא שהם עלו בצורה תקינה ויש להם 2 כתובות IP חיצונית ופנימית:

IPERF3


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

NMON


.UDP וגם TCP הוא הכלי הסינטטי איתו נריץ בדיקות. הכלי מסוגל לייצר תעבורת
הכלי דורש לפחות 2 מכונות: אחד ירוץ כשרת והשני ירוץ כלקוח.


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

IPTRAF


כלי ותיק לניטור ביצועי הרשת. מאוד שימושי בבדיקות ביצועי רשת.

MTR


ומאפשר בין היתר לשמור את המידע ע"ג קבצים Ping ובין Tracerouteכלי יעיל שמשלב בין  
:yum / apt-getההתקנה יחסית פשוטה במידה ונשתמש ב-

yum install <package-name> -y
apt-get install <package-name> -y

לפני שנתחיל בבדיקה הסינטטית, נריץ מספר פקודות בסיסיות ונבחן את הפלט שלהן:

ifconfig
ethtool eth0
traceroute cnn.com
mtr cnn.com

האם שמתם לב להבדלים בין מערכת GCP לבין האינסטנס ב-BARE METAL?


חזרה לבדיקה הסינטטית שלנו

:IPERFלאחר שהתקנו את הכלים, נרים שרת  


iperf3 -s

ומהמכונה השנייה נדמה את הלקוח ונריץ את הבדיקה:


iperf3 -c <your-server-ip> -B0 -P <number-of-clients>


מה בעצם ביקשנו להריץ?


 ולהעביר את המקסימום מקצה לקצהTCPפנינו לשרת שמאזין בצד השני וביקשנו להריץ בדיקת  
man iperf3מידע על כל האפשרויות הזמינות אפשר לקבל דרך אם נריץ  

"SUMאת התוצאות של הבדיקה נקבל בסופה גם בצד השרת וגם בצד הלקוח בשורת ה"


מה למדנו מהבדיקה


הקמנו 2 מכונות שמריצות לינוקס ולמדנו להריץ בדיקת מהירות סינטטית בין שני שרתים.
את הבדיקה הפשוטה יחסית נוכל לפתח לסט בדיקות בין משאבים שנמצאים באזורים שונים, דרך
או הרשת הציבורית, על מנת לבדוק את ביצועי הרשת, חווית המשתמש ויציבות ה-VPN, Peering
וה-Workload שלנו.

ראינו גם את ההבדלים בין מערכות bare metal לבין הרשת ב-GCP:

- בהרצה של ETHTOOL לדוגמא, נראה מידע מצומצם על ה-ETH שלנו.
- 1460 MTU נכון לזמן כתיבת המאמר זו הגבלה קשיחה של התשתית, אולם יש לגוגל תוכניות
 עתידיות להציע גם 9000 MTU – Jumbo Frames.
- אם נריץ traceroute cnn.com לדוגמא, הפלט שנקבל יהיה מוסתר בכוכביות, לכן נעדיף להשתמש
 ב-MTR - My trace route.


מה מצפה לנו בעולם האמיתי


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

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

- נבחר באזור גיאוגרפי שקרוב למשתמשים שלנו כדי למנוע עיכובים שנוצרים מאיטיות ברשת

- נבחר בקפידה את גודל האינסטנסים שלנו: מספר הליבות במעבד שנבחר יקבע את המקסימום
 throughput שאליו נגיע

- ייתכן ונצטרך להגדיר פרמטרים נוספים, על מנת לשפר את הביצועים  
 ברמת מערכת ההפעלה. מדריך מקיף בנושא אפשר למצוא כאן והיכרות עם לינוקס היא הכרחית:  
 https://www.slashroot.in/linux-network-tcp-performance-tuning-sysctl

- CDN במידה ויש לנו קבצי מדיה או קבצים סטטיים, נרצה בוודאות לשקול את השימוש ב-CDN  
 שיוריד מאיתנו את העומס וישרת את הלקוחות שלנו מנקודה קרובה יותר, מה שיתבטא בטעינה
 מהירה יותר של אובייקטים.

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

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

בהצלחה!


לקריאה נוספת:

https://cloud.google.com/compute/docs/machine-types
https://cloud.google.com/docs/enterprise/best-practices-for-enterprise-organizations
https://cloud.google.com/compute/docs/cpu-platforms

https://cloud.google.com/vpc/

https://cloud.google.com/blog/products/gcp/5-steps-to-better-gcp-network-performance?hl=ml
https://cloud.google.com/blog/products/compute/introducing-compute-and-memory-optimized-vms-for-google-compute-engine

מאת: מתן גרביץ
matan.gr

לפרטים נוספים ויצירת קשר עם נציג אורקל

תודה הודעתך התקבלה

הודעתך לא התקבלה - נסה שוב מאוחר יותר

מתן גרביץ

הירשם לרשימת הדיוור של IsraelClouds

Thank you! Your submission has been received!

Oops! Something went wrong while submitting the form

מילון מונחיםהשירותים שלנו תנאי שימושהרשמה לניוזלטרמדיניות פרטיות