ProHoster > بلوق > إدارة > بناء وتكوين CDN الخاص بك

بناء وتكوين CDN الخاص بك

تُستخدم شبكات توصيل المحتوى (CDN) في مواقع الويب والتطبيقات بشكل أساسي لتسريع تحميل العناصر الثابتة. يحدث هذا بسبب التخزين المؤقت للملفات على خوادم CDN الموجودة في مناطق جغرافية مختلفة. من خلال طلب البيانات عبر CDN، يحصل المستخدم عليها من أقرب خادم.

مبدأ التشغيل والوظيفة لجميع شبكات توصيل المحتوى هو نفسه تقريبًا. بعد تلقي طلب لتنزيل ملف، يأخذ خادم CDN الملف مرة واحدة من الخادم الأصلي ويعطيه للمستخدم، وفي نفس الوقت يقوم بتخزينه مؤقتًا لفترة زمنية محددة. يتم الرد على جميع الطلبات اللاحقة من ذاكرة التخزين المؤقت. تحتوي جميع شبكات CDN على خيارات للتحميل المسبق للملفات، ومسح ذاكرة التخزين المؤقت، وتعيين تاريخ انتهاء الصلاحية، والمزيد.

يحدث ذلك لسبب أو لآخر، تحتاج إلى تنظيم شبكة توصيل المحتوى الخاصة بك، وبعد ذلك - دع تعليمات تجميع الدراجة التالية تساعدنا.

بناء وتكوين CDN الخاص بك
المصدر: ناقل المعلومات الذي تم إنشاؤه بواسطة pikisuperstar - www.freepik.com

عندما تحتاج إلى CDN الخاص بك

ضع في اعتبارك الحالات التي يكون فيها تشغيل CDN الخاص بك أمرًا منطقيًا:

  • عندما تكون هناك رغبة في توفير المال، وتكاليف التشغيل حتى عند استخدام شبكات CDN غير مكلفة مثل الأرنب يصل إلى عدة مئات من الدولارات شهريا
  • إذا أردنا الحصول على ذاكرة تخزين مؤقت دائمة أو ذاكرة تخزين مؤقت بدون جيران الخادم والقناة
  • لا تتمتع خدمات CDN بنقاط تواجد في المنطقة التي تحتاجها
  • أي إعدادات خاصة لتسليم المحتوى مطلوبة
  • نريد تسريع عملية تسليم المحتوى الديناميكي من خلال وضع خادم الإنتاج بالقرب من المستخدمين
  • هناك مخاوف من أن خدمة CDN تابعة لجهة خارجية قد تقوم بجمع أو استخدام معلومات حول سلوك المستخدم بشكل غير قانوني (مرحبًا بالخدمات غير المتوافقة مع اللائحة العامة لحماية البيانات) أو الانخراط في أنشطة غير قانونية أخرى

وفي معظم الحالات الأخرى، يكون من الأنسب استخدام الحلول الجاهزة الموجودة.

ماذا تحتاج لتبدأ

إنه لأمر رائع أن يكون لديك نظام الحكم الذاتي الخاص بك (AS). باستخدامه، يمكنك تعيين نفس عنوان IP لعدة خوادم و وفقا لهذه التعليمات على مستوى الشبكة، قم بتوجيه المستخدمين إلى أقرب واحد. تجدر الإشارة إلى أنه حتى مع كتلة العنوان/24، من الممكن إنشاء شبكة لتوصيل المحتوى. يسمح لك بعض موفري الخوادم بإصدار إعلان للاستخدام في جميع المناطق المتاحة لهم.

إذا لم تكن مالكًا سعيدًا لمجموعة من عناوين IP، فستحتاج لتشغيل CDN بسيط:

  • اسم المجال أو المجال الفرعي
  • خادمين على الأقل في مناطق مختلفة. يمكن أن يكون الخادم مخصصًا أو افتراضيًا
  • أداة GeoDNS. باستخدامه، سيتم توجيه المستخدم، بعد معالجة المجال، إلى أقرب خادم

تسجيل المجال وطلب الخوادم

مع تسجيل النطاق، كل شيء بسيط - نقوم بالتسجيل في أي منطقة لدى أي مسجل. يمكنك أيضًا استخدام نطاق فرعي لشبكة CDN، على سبيل المثال شيء من هذا القبيل cdn.domainname.com. في الواقع، في مثالنا، سنفعل ذلك تمامًا.

أما بالنسبة لطلب الخوادم، فيجب استئجارها في المناطق والبلدان التي يتواجد فيها جمهور المستخدم الخاص بك. إذا كان المشروع عابرا للقارات، فمن المناسب اختيار موفري الاستضافة الذين يقدمون خوادم في جميع أنحاء العالم في وقت واحد. أمثلة: OVH, ليسويب и 100Tb - للخوادم المخصصة، Vultr и DigitalOcean — للسحابة الافتراضية*.

بالنسبة لشبكة CDN الخاصة بنا، سنطلب 3 خوادم افتراضية في قارات مختلفة. في Vultr على الخادم ل 5 دولارات شهريًا سوف نحصل 25GB SSD الأماكن و 1 تيرابايت من حركة المرور. عند التثبيت، حدد أحدث إصدار من Debian. خوادمنا:

بناء وتكوين CDN الخاص بك فرانكفورت، ايب: 199.247.18.199

بناء وتكوين CDN الخاص بك شيكاغو، ايب: 149.28.121.123

بناء وتكوين CDN الخاص بك سنغافورة، ايب: 157.230.240.216

*تعد Vultr وDigitalOcean برصيد قدره 100 دولار للمستخدمين الذين يقومون بالتسجيل من خلال الروابط الموجودة في المقالة فورًا بعد إضافة طريقة الدفع. يتلقى المؤلف أيضًا مجاملة صغيرة من هذا، وهو أمر مهم جدًا بالنسبة له الآن. يرجى أن يكون الفهم.

إعداد GeoDNS

لكي يتم توجيه المستخدم إلى الخادم المطلوب (الأقرب) عند الوصول إلى مجال أو نطاق فرعي لـ CDN، نحتاج إلى خادم DNS مزود بوظيفة GeoDNS.

مبدأ وتشغيل GeoDNS هو كما يلي:

  1. يحدد عنوان IP الخاص بالعميل الذي أرسل طلب DNS، أو عنوان IP الخاص بخادم DNS العودي الذي يتم استخدامه عند معالجة طلب العميل. عادةً ما تكون هذه الخوادم العودية عبارة عن DNS لموفري الخدمة.
  2. يتعرف IP الخاص بالعميل على بلده أو منطقته. لهذا، يتم استخدام قواعد بيانات GeoIP، والتي يوجد عدد كبير منها اليوم. هناك جيدة خيارات مجانية.
  3. اعتمادا على موقع العميل، يمنحه عنوان IP الخاص بأقرب خادم CDN.

يمكن أن يكون خادم DNS مع وظيفة GeoDNS تجميع بنفسكولكن من الأفضل استخدام الحلول الجاهزة مع شبكة من خوادم DNS حول العالم و مختلفة الإرسال من الصندوق:

  • CloudDNS من 9.95 دولارات شهريًا، تعريفة GeoDNS، بشكل افتراضي هناك تجاوز فشل DNS واحد
  • زيلور من 25 دولارات شهريًاتم تمكين تجاوز فشل DNS
  • الأمازون الطريق 53 من 35 دولارات شهريًا للحصول على صافي 50 مليون طلب جغرافي. تتم محاسبة فشل DNS بشكل منفصل
  • جعل DNS سهلاً من 125 دولارات شهريًا، هناك 10 حالات فشل DNS
  • كلودفلاري، تتوفر ميزة "Geo Steering" في خطط المؤسسات

عند طلب GeoDNS، يجب عليك الانتباه إلى عدد الطلبات المضمنة في التعريفة وتذكر أن العدد الفعلي لطلبات النطاق يمكن أن يتجاوز التوقعات عدة مرات. يعمل الملايين من العناكب والماسحات الضوئية ومرسلي البريد العشوائي والأرواح الشريرة الأخرى بلا كلل.

تشتمل جميع خدمات DNS تقريبًا على خدمة لا غنى عنها لبناء CDN - DNS Failover. بمساعدتها، يمكنك إعداد مراقبة تشغيل الخوادم الخاصة بك، وفي حالة عدم وجود علامات الحياة، قم تلقائيًا باستبدال عنوان الخادم غير العامل بعنوان احتياطي في استجابات DNS.

لبناء CDN الخاص بنا، سوف نستخدم كلاودنستعريفة GeoDNS.

دعونا نضيف منطقة DNS جديدة في حسابك الشخصي، مع تحديد المجال الخاص بك. إذا كنا نبني CDN على مجال فرعي، وكان المجال الرئيسي قيد الاستخدام بالفعل، فلا تنس بعد إضافة المنطقة مباشرة إضافة سجلات DNS العاملة الحالية. الخطوة التالية هي إنشاء عدة سجلات A لمجال CDN / المجال الفرعي، وسيتم تطبيق كل منها على المنطقة التي حددناها. يمكنك تحديد القارات أو البلدان كمناطق، وتتوفر المناطق الفرعية للولايات المتحدة الأمريكية وكندا.

في حالتنا، سيتم رفع CDN على نطاق فرعي cdn.sayt.in. عن طريق إضافة منطقة sayt.in، أنشئ أول سجل A للنطاق الفرعي وقم بتوجيه كل أمريكا الشمالية إلى الخادم في شيكاغو:

بناء وتكوين CDN الخاص بك
دعونا نكرر الإجراء للمناطق الأخرى، مع تذكر إنشاء إدخال واحد للمناطق الافتراضية. إليك ما يحدث في النهاية:

بناء وتكوين CDN الخاص بك

الإدخال الافتراضي الأخير في لقطة الشاشة يعني أنه سيتم إرسال جميع المناطق غير المحددة (وهي أوروبا وإفريقيا ومستخدمي الإنترنت عبر الأقمار الصناعية وما إلى ذلك) إلى الخادم في فرانكفورت.

هذا يكمل إعداد DNS الأساسي. يبقى الانتقال إلى موقع الويب الخاص بمسجل النطاق واستبدال NS للمجال الحالي بتلك الصادرة عن ClouDNS. وبينما سيتم تحديث NS، سنقوم بإعداد الخوادم.

تركيب شهادات SSL

سيعمل CDN الخاص بنا عبر HTTPS، لذلك إذا كان لديك بالفعل شهادات SSL لمجال أو نطاق فرعي، فقم بتحميلها على جميع الخوادم، على سبيل المثال، إلى الدليل /الخ/ssl/yourdomain/

إذا لم تكن هناك شهادات، فيمكنك الحصول على شهادة مجانية من Let's Encrypt. مثالي لهذا ACME شلسكريبت. يعد العميل ملائمًا وسهل الإعداد، والأهم من ذلك أنه يسمح لك بالتحقق من صحة النطاق/النطاق الفرعي عن طريق DNS عبر ClouDNS API.

سنقوم بتثبيت acme.sh على خادم واحد فقط - الأوروبي 199.247.18.199، والذي سيتم نسخ الشهادات منه إلى جميع الخوادم الأخرى. للتثبيت، قم بتشغيل:

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

أثناء تثبيت البرنامج النصي، سيتم إنشاء وظيفة CRON لمزيد من تجديد الشهادات دون مشاركتنا.

عند إصدار شهادة، سيتم فحص النطاق باستخدام DNS باستخدام واجهة برمجة التطبيقات (API)، لذلك في حساب ClouDNS الشخصي في قائمة Reseller API، تحتاج إلى إنشاء واجهة برمجة تطبيقات مستخدم جديدة وتعيين كلمة مرور لها. سيتم كتابة معرف المصادقة الناتج بكلمة مرور في الملف ~/.acme.sh/dnsapi/dns_cloudns.sh (يجب عدم الخلط بينه وبين file 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"

في الخيارات، قمنا بتحديد أمر للمستقبل لإعادة تحميل تكوين خادم الويب تلقائيًا بعد كل تجديد لفترة صلاحية الشهادة في المستقبل.

يمكن أن تستغرق عملية الحصول على الشهادة بأكملها ما يصل إلى دقيقتين، فلا تقاطعها. في حالة حدوث خطأ في التحقق من صحة المجال، حاول تشغيل الأمر مرة أخرى. في النهاية سنرى أين تم تحميل الشهادات:

بناء وتكوين CDN الخاص بك

تذكر هذه المسارات، يجب تحديدها عند نسخ الشهادة إلى خوادم أخرى، وكذلك في إعدادات خادم الويب. نحن لا ننتبه إلى خطأ إعادة تحميل إعدادات Nginx - فلن يكون على خادم مهيأ بالكامل عند تحديث الشهادات.

كل ما تبقى لنا لـ SSL هو نسخ الشهادة المستلمة إلى خادمين آخرين مع الحفاظ على المسار إلى الملفات. لنقم بإنشاء نفس المجلدات على كل منها ونقوم بعمل نسخة منها:

root@cdn:~# mkdir -p /root/.acme.sh/cdn.sayt.in/
root@cdn:~# scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/

لتحديث الشهادات بانتظام، قم بإنشاء مهمة CRON يومية على كلا الخادمين باستخدام الأمر:

scp -r [email protected]:/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 تيرابايت من حركة المرور: 1 تيرابايت في كل موقع.

التحقق من عمل CDN

دعونا نلقي نظرة على الأصوات التي تصل إلى CDN الخاص بنا من مواقع جغرافية مختلفة. ستعمل أي خدمة ping على هذا الغرض.

نقطة الانطلاق
يستضيف
IP
متوسط ​​الوقت، مللي ثانية

ألمانيا برلين
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.
تطهير.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، مما يساعد على تغيير السجل A بسرعة في حالة تعطل الخادم. يتم ذلك في سجلات DNS الخاصة بلوحة التحكم الخاصة بالمجال.
  • لا شك أن المواقع ذات التغطية الجغرافية الواسعة تتطلب عددًا كبيرًا من شبكات CDN، ولكن دعونا لا نكون متعصبين. على الأرجح لن يلاحظ المستخدم فرقًا كبيرًا مقارنة بشبكة CDN المدفوعة إذا قمت بوضع خوادم في 6-7 مواقع: أوروبا أو أمريكا الشمالية (شرقًا) أو أمريكا الشمالية (غربًا) أو سنغافورة أو أستراليا أو هونج كونج أو اليابان.
  • في بعض الأحيان لا يسمح المضيفون باستخدام الخوادم المستأجرة لأغراض CDN. لذلك، إذا قررت فجأة نشر شبكة توصيل المحتوى كخدمة، فلا تنس قراءة قواعد مزود استضافة معين مسبقًا
  • يكتشف خريطة الاتصالات تحت الماءلتمثيل كيفية اتصال القارات وأخذ ذلك في الاعتبار عند بناء شبكة توصيل المحتوى
  • حاول التحقق الأصوات من أماكن مختلفة إلى خوادمك. بهذه الطريقة يمكنك رؤية المناطق الأقرب إلى نقاط CDN وتكوين GeoDNS بشكل أكثر صحة
  • اعتمادًا على المهام، سيكون من المفيد ضبط Nginx ليناسب متطلبات التخزين المؤقت المحددة مع مراعاة التحميل على الخادم. ساعدتني المقالات حول ذاكرة التخزين المؤقت لـ Nginx كثيرًا في هذا - هنا وتسريع العمل تحت الأحمال الثقيلة: هنا и هنا

المصدر: www.habr.com