4 שאלות שכדאי לקחת בחשבון כשאתה בוחר ספק DNS חיצוני - IBM Blog

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

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

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

בזמן שאתה מרכיב את רשימת ה"חובה" שלך, ריכזנו כמה שאלות שיכולות לעזור לבנות את רשימת הדרישות שלך.

1. מה פרופיל הסיכון שלך?

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

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

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

2. מה המפתחים שלך צריכים?

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

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

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

3. איך תנהל תעבורה בין מספר CDNs ו/או עננים?

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

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

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

4. כמה חשוב הביצועים?

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

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

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

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

למידע נוסף על פתרון ה-DNS המנוהל של IBM NS1 Connect.