אירוח בענן (Cloud Hosting)

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

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

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

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

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

מה הפירוש של אירוח ענן?

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

מה הפירוש של IaaS?

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

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

מי שרוצה לקנות אירוח בענן בדרך כלל צריך:

• החלטה על גודל שרת הענן (גודל זיכרון מרבי, באופן מהותי)

• בחר מערכת הפעלה (אובונטו 64 ביט, CentOS, Windows Server וכן הלאה) ובמידת הצורך שרת מסד נתונים (למשל שרת Microsoft MySQL)

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

   

מאפייני אירוח ענן טוב

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

אירוח ענן: מי משתמש בו?

למרות זאת מדובר במגמה רחבה של גוגל - עלייה של 50% בהשוואה לאירוח מסורתי על פי סקר שערכה Rackspace, כ- 60-70% מהנשאלים של ארגונים קטנים ובינוניים אינם מכירים זאת. טכנולוגיה. אולי הדרך הטובה ביותר להבין טוב יותר על מה אנחנו מדברים היא לרשום כמה דוגמאות לשימוש:

• אחסון נתונים (קבצים ו / או כמויות גדולות של נתונים)

• אירוח אתרים (ניהול תזרימי תנועה אדירים)

• הגדלת עיבוד / עומסי עבודה מבוזרים (ניהול עומסי עבודה טוב יותר)

• אחסון קבצים ומסדי נתונים

• אירוח אפליקציות

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

1. החברות המציעות אירוח בענן עדיין אינן רבות במיוחד

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

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

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

מאירוח משותף לאחסון ענן

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

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

אירוח ענן: ניתן להרחבה ומופץ

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

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

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

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

לוח בקרה ומדרגיות

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

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

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

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

גישה SSH

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

תמחור שירותי אירוח ענן

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

לאן הולך אירוח ענן מנוהל?

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

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