ProHoster > בלוג > מינהל > בנייה והגדרה של ה-CDN שלך

בנייה והגדרה של ה-CDN שלך

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

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

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

בנייה והגדרה של ה-CDN שלך
מקור: וקטור אינפוגרפי שנוצר על ידי pikisuperstar - www.freepik.com

כאשר אתה צריך CDN משלך

שקול את המקרים שבהם הפעלת CDN משלך הגיונית:

  • כאשר יש רצון לחסוך כסף, ועלויות שוטפות גם כאשר משתמשים ב-CDN זולים כמו BunnyCDN סכום של כמה מאות דולרים בחודש
  • אם אנחנו רוצים לקבל מטמון קבוע או מטמון ללא שכני שרת וערוצים
  • לשירותי CDN אין נקודות נוכחות באזור שאתה צריך
  • כל הגדרות מיוחדות להעברת תוכן הנדרשות
  • אנו רוצים להאיץ את אספקת התוכן הדינמי על ידי הצבת שרת הייצור קרוב יותר למשתמשים
  • קיים חשש ששירות CDN של צד שלישי עלול לאסוף או להשתמש באופן לא חוקי במידע על התנהגות משתמשים (שלום שירותים שאינם תואמים ל-GDPR) או לעסוק בפעילויות בלתי חוקיות אחרות

ברוב המקרים האחרים, נכון יותר להשתמש בפתרונות מוכנים קיימים.

מה אתה צריך כדי להתחיל

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

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

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

רישום דומיין והזמנת שרתי

עם רישום דומיין, הכל פשוט - אנו נרשמים בכל אזור עם כל רשם. אתה יכול גם להשתמש בתת-דומיין עבור CDN, למשל משהו כמו cdn.domainname.com. למעשה, בדוגמה שלנו, נעשה בדיוק את זה.

לגבי הזמנת שרתים, יש לשכור אותם באזורים ובמדינות שבהם נמצא קהל המשתמשים שלך. אם הפרויקט הוא בין יבשתי, אז נוח לבחור ספקי אחסון המציעים שרתים בכל העולם בבת אחת. דוגמאות: OVH, רשת חכירה и 100Tb - עבור שרתים ייעודיים, וולטר и DigitalOcean - לענן וירטואלי*.

עבור ה-CDN הפרטי שלנו, נזמין 3 שרתים וירטואליים ביבשות שונות. בְּ וולטר בשרת עבור 5 דולר לחודש אנו נקבל 25GB SSD מקומות ו 1TB של תעבורה. בעת ההתקנה, בחר את ה-Debian העדכנית ביותר. השרתים שלנו:

בנייה והגדרה של ה-CDN שלך פרנקפורט, ip: 199.247.18.199

בנייה והגדרה של ה-CDN שלך שיקגו, ip: 149.28.121.123

בנייה והגדרה של ה-CDN שלך סינגפור, ip: 157.230.240.216

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

הגדרת geoDNS

על מנת שהמשתמש יופנה לשרת הרצוי (הקרוב ביותר) בעת גישה לדומיין או תת-דומיין CDN, אנו זקוקים לשרת DNS עם פונקציית geoDNS.

העיקרון והתפעול של geoDNS הם כדלקמן:

  1. מציין את ה-IP של הלקוח ששלח את בקשת ה-DNS, או את ה-IP של שרת ה-DNS הרקורסי שבו נעשה שימוש בעת עיבוד בקשת הלקוח. שרתים רקורסיביים כאלה הם בדרך כלל DNS-s של ספקים.
  2. ה-IP של הלקוח מזהה את המדינה או האזור שלו. לשם כך משתמשים בבסיסי נתונים של GeoIP, מהם יש הרבה מאוד היום. יש טובים אפשרויות חינמיות.
  3. בהתאם למיקום הלקוח, נותן לו את כתובת ה-IP של שרת ה-CDN הקרוב.

שרת DNS עם פונקציית geoDNS יכול להיות להרכיב לבד, אבל עדיף להשתמש בפתרונות מוכנים עם רשת של שרתי DNS ברחבי העולם ו Anycast מהקופסה:

  • CloudDNS מ 9.95 דולר לחודש, תעריף GeoDNS, כברירת מחדל קיים DNS Failover אחד
  • זילור מ 25 דולר לחודש, כשל ב-DNS מופעל
  • כביש אמזון 53 מ 35 דולר לחודש עבור 50 מיליון בקשות גיאוגרפיות נטו. ה-DNS Failover מחויב בנפרד
  • DNS קל מ 125 דולר לחודש, יש 10 כשל ב-DNS
  • Cloudflare, תכונת "היגוי גיאוגרפי" זמינה בתוכניות ארגוניות

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

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

כדי לבנות את ה-CDN שלנו, נשתמש CloudDNS, תעריף GeoDNS.

בוא נוסיף אזור DNS חדש בחשבון האישי שלך, תוך ציון הדומיין שלך. אם אנחנו בונים CDN על תת-דומיין, והדומיין הראשי כבר בשימוש, אז מיד לאחר הוספת האזור, אל תשכח להוסיף את רשומות ה-DNS הפועלות הקיימות. השלב הבא הוא יצירת מספר רשומות A עבור תחום CDN/תת-דומיין, שכל אחת מהן תחול על האזור שציינו. אתה יכול לציין יבשות או מדינות כאזורים, אזורי משנה זמינים עבור ארה"ב וקנדה.

במקרה שלנו, ה-CDN יועלה על תת-דומיין cdn.sayt.in. על ידי הוספת אזור sayt.in, צור את רשומת ה-A הראשונה עבור תת-הדומיין והפנה את כל צפון אמריקה לשרת בשיקגו:

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

בנייה והגדרה של ה-CDN שלך

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

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

התקנת תעודות SSL

ה-CDN שלנו יעבוד על HTTPS, אז אם כבר יש לך אישורי SSL עבור דומיין או תת-דומיין, העלה אותם לכל השרתים, למשל, לספרייה /etc/ssl/yourdomain/

אם אין אישורים, אתה יכול לקבל אחד בחינם מ-Let's Encrypt. מושלם עבור זה סקריפט של ACME Shell. הלקוח נוח וקל להגדרה, והכי חשוב, הוא מאפשר לך לאמת דומיין/תת-דומיין על ידי DNS דרך ה-API של ClouDNS.

נתקין acme.sh רק על אחד מהשרתים - אירופאי 199.247.18.199, ממנו יועתקו תעודות לכל השאר. כדי להתקין, הפעל:

root@cdn:~# wget -O - https://get.acme.sh | bash; source ~/.bashrc

במהלך התקנת הסקריפט תיווצר משרת CRON לחידוש תעודות נוסף ללא השתתפותנו.

בעת הנפקת אישור, הדומיין ייבדק באמצעות DNS באמצעות ה-API, כך שבחשבון האישי של ClouDNS בתפריט Reseller API, עליך ליצור API חדש למשתמש ולהגדיר עבורו סיסמה. מזהה ההסמכה שיתקבל עם סיסמה ייכתב בקובץ ~/.acme.sh/dnsapi/dns_cloudns.sh (לא להתבלבל עם קובץ dns_clouddns.sh). להלן השורות שיש לבטל הערות ולערוך:

CLOUDNS_AUTH_ID=<auth-id>
CLOUDNS_AUTH_PASSWORD="<пароль>"

כעת נבקש תעודת SSL עבור cdn.sayt.in

root@cdn:~# acme.sh --issue --dns dns_cloudns -d cdn.sayt.in --reloadcmd "service nginx reload"

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

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

בנייה והגדרה של ה-CDN שלך

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

כל שנותר לנו ל-SSL הוא להעתיק את האישור שהתקבל לשני שרתים אחרים תוך שמירה על הנתיב לקבצים. בואו ניצור את אותן ספריות על כל אחת מהן וניצור עותק:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

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

scp -r root@199.247.18.199:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

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

התקנה והגדרה של Nginx

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

root@cdn:~# apt update
root@cdn:~# apt install nginx

במקום ברירת המחדל, אנו משתמשים בתצורה מהספוילר למטה:
nginx.conf

user www-data;
worker_processes auto;
pid /run/nginx.pid;

events {
    worker_connections 4096;
    multi_accept on;
}

http {
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    types_hash_max_size 2048;

    include /etc/nginx/mime.types;
    default_type application/octet-stream;

    access_log off;
    error_log /var/log/nginx/error.log;

    gzip on;
    gzip_disable "msie6";
    gzip_comp_level 6;
    gzip_proxied any;
    gzip_vary on;
    gzip_types text/plain application/javascript text/javascript text/css application/json application/xml text/xml application/rss+xml;
    gunzip on;            

    proxy_temp_path    /var/cache/tmp;
    proxy_cache_path   /var/cache/cdn levels=1:2 keys_zone=cdn:64m max_size=20g inactive=7d;
    proxy_cache_bypass $http_x_update;

server {
  listen 443 ssl;
  server_name cdn.sayt.in;

  ssl_certificate /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.cer;
  ssl_certificate_key /root/.acme.sh/cdn.sayt.in/cdn.sayt.in.key;

  location / {
    proxy_cache cdn;
    proxy_cache_key $uri$is_args$args;
    proxy_cache_valid 90d;
    proxy_pass https://sayt.in;
    }
  }
}

ערוך בתצורה:

  • גודל מקסימלי - גודל המטמון, לא חורג משטח הדיסק הזמין
  • פעיל - זמן אחסון של נתונים מאוחסנים שאיש לא ניגש אליהם
  • ssl_certificate и ssl_certificate_key - נתיבים לאישור SSL וקבצי מפתח
  • proxy_cache_valid - זמן אחסון של נתונים במטמון
  • proxy_pass - כתובת השרת המקורי שממנו ה-CDN יבקש קבצים לאחסון במטמון. בדוגמה שלנו, זה sayt.in

כפי שאתה יכול לראות, הכל פשוט. קושי יכול להתעורר רק בקביעת זמן האחסון במטמון בגלל הדמיון בין ההנחיות פעיל и proxy_cache_valid. בואו ננתח אותם עם הדוגמה שלנו. הנה מה קורה מתי לא פעיל=7 ימים и proxy_cache_valid 90d:

  • אם הבקשה לא תחזור בתוך 7 ימים, הנתונים יימחקו מהמטמון לאחר תקופה זו
  • אם הבקשה חוזרת על עצמה לפחות פעם ב-7 ימים, הנתונים במטמון ייחשבו מיושנים לאחר 90 יום ו-Nginx תעדכן אותם בבקשה הבאה, וייקח אותם מהשרת המקורי

סיים לערוך nginx.conf, טען מחדש את התצורה:

root@cdn:~# service nginx reload

ה-CDN שלנו מוכן. תמורת $15 לחודש. קיבלנו נקודות נוכחות בשלוש יבשות ו-3 TB של תעבורה: 1 TB בכל מיקום.

בדיקת עבודת CDN

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

נקודת השקה
מארח
IP
זמן ממוצע, MS

גרמניה ברלין
cdn.sayt.in
199.247.18.199
9.6

הולנד, אמסטרדם
cdn.sayt.in
199.247.18.199
10.1

צרפת פריז
cdn.sayt.in
199.247.18.199
16.3

בריטניה הגדולה, לונדון
cdn.sayt.in
199.247.18.199
14.9

קנדה, טורונטו
cdn.sayt.in
149.28.121.123
16.2

ארה"ב, סן פרנסיסקו
cdn.sayt.in
149.28.121.123
52.7

ארה"ב, דאלאס
cdn.sayt.in
149.28.121.123
23.1

ארה"ב, שיקגו
cdn.sayt.in
149.28.121.123
2.6

ארה"ב, ניו יורק
cdn.sayt.in
149.28.121.123
19.8

סינגפור
cdn.sayt.in
157.230.240.216
1.7

יפן טוקיו
cdn.sayt.in
157.230.240.216
74.8

אוסטרליה, סידני
cdn.sayt.in
157.230.240.216
95.9

התוצאות טובות. כעת נמקם תמונת בדיקה בשורש האתר הראשי test.jpg ובדוק את מהירות ההורדה שלו דרך CDN. זה נאמר - נעשה. התוכן מועבר במהירות.

בוא נכתוב סקריפט קטן למקרה שנרצה לנקות את המטמון בנקודת ה-CDN.
purge.sh

#!/bin/bash
if [ -z "$1" ]
then
    echo "Purging all cache"
    rm -rf /var/cache/cdn/*
else
    echo "Purging $1"
    FILE=`echo -n "$1" | md5sum | awk '{print $1}'`
    FULLPATH=/var/cache/cdn/${FILE:31:1}/${FILE:29:2}/${FILE}
    rm -f "${FULLPATH}"
fi

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

root@cdn:~# ./purge.sh /test.jpg

במקום מסקנות

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

  • כדי להגביר את סבילות התקלות של ה-CDN, מומלץ להגדיר את ה-DNS Failover, שעוזר לשנות במהירות את רשומת A במקרה של תקלה בשרת. זה נעשה ברשומות DNS של לוח הבקרה של הדומיין.
  • אתרים עם כיסוי גיאוגרפי רחב ללא ספק דורשים מספר רב של CDNs, אבל בואו לא נהיה פנאטים. סביר להניח שהמשתמש לא יבחין בהבדל משמעותי בהשוואה ל-CDN בתשלום אם תציב שרתים ב-6-7 מיקומים: אירופה, צפון אמריקה (מזרח), צפון אמריקה (מערב), סינגפור, אוסטרליה, הונג קונג או יפן
  • לפעמים מארחים אינם מאפשרים שימוש בשרתים מושכרים למטרות CDN. לכן, אם החלטתם לפתע לפרוס רשת אספקת תוכן כשירות, אל תשכחו לקרוא מראש את הכללים של ספק אירוח מסוים
  • לַחקוֹר מפת תקשורת מתחת למיםלייצג את האופן שבו היבשות מחוברות ולקחת זאת בחשבון בעת ​​בניית רשת אספקת תוכן
  • תנסה לבדוק פינג ממקומות שונים לשרתים שלך. כך תוכלו לראות את האזורים הקרובים ביותר לנקודות CDN ולהגדיר את GeoDNS בצורה נכונה יותר
  • בהתאם למשימות, יהיה שימושי לכוונון עדין של Nginx לדרישות מטמון ספציפיות ובהתחשב בעומס על השרת. המאמרים על מטמון Nginx עזרו לי מאוד בזה - כאן והאצת עבודה בעומסים כבדים: כאן и כאן

מקור: www.habr.com