🥇तपाईँको CDN सङ्कलन र सेटअप गर्दै

सामग्री डेलिभरी नेटवर्कहरू (CDNs) वेबसाइटहरू र अनुप्रयोगहरूमा मुख्य रूपमा स्थिर तत्वहरूको लोडिङ गति बढाउन प्रयोग गरिन्छ। यो विभिन्न भौगोलिक क्षेत्रहरूमा अवस्थित CDN सर्भरहरूमा फाइलहरूको क्यासिंगको कारणले हुन्छ। CDN मार्फत डाटा अनुरोध गरेर, प्रयोगकर्ताले यसलाई नजिकको सर्भरबाट प्राप्त गर्दछ।

सबै सामग्री वितरण नेटवर्कहरूको सञ्चालन र कार्यक्षमताको सिद्धान्त लगभग समान छ। फाइल डाउनलोड गर्न अनुरोध प्राप्त गरेपछि, CDN सर्भरले यसलाई मूल सर्भरबाट एक पटक लिन्छ र प्रयोगकर्तालाई दिन्छ, एकै समयमा निर्दिष्ट समयको लागि क्यास गर्दै। सबै पछिका अनुरोधहरू क्यासबाट जवाफ दिइन्छ। सबै CDN सँग फाइलहरू प्रिलोड गर्ने, क्यास खाली गर्ने, म्याद सकिने मिति सेट गर्ने र थप कुराहरू छन्।

यो हुन्छ कि, एक वा अर्को कारण को लागी, तपाइँ तपाइँको आफ्नै सामग्री डेलिभरी नेटवर्क संगठित गर्न आवश्यक छ, र त्यसपछि - अर्को बाइक को संयोजन को लागी निर्देशनहरु लाई हामीलाई मद्दत गर्न दिनुहोस्।

स्रोत: इन्फोग्राफिक वेक्टर pikisuperstar द्वारा बनाईएको - www.freepik.com

जब तपाईलाई आफ्नै CDN चाहिन्छ

तपाईंको आफ्नै CDN चलाउँदा अर्थपूर्ण अवस्थामा विचार गर्नुहोस्:

जब त्यहाँ पैसा बचत गर्ने इच्छा हुन्छ, र सस्तो CDNs प्रयोग गर्दा पनि चलिरहेको लागत BunnyCDN महिनामा धेरै सय डलरको रकम
यदि हामी सर्भर र च्यानल छिमेकीहरू बिना स्थायी क्यास वा क्यास प्राप्त गर्न चाहन्छौं
CDN सेवाहरूसँग तपाईलाई आवश्यक पर्ने क्षेत्रमा उपस्थितिको बिन्दुहरू छैनन्
कुनै विशेष सामग्री वितरण सेटिङहरू आवश्यक छ
हामी उत्पादन सर्भरलाई प्रयोगकर्ताहरूको नजिक राखेर गतिशील सामग्रीको डेलिभरीलाई गति दिन चाहन्छौं
त्यहाँ एक चिन्ता छ कि तेस्रो-पक्ष CDN सेवाले अवैध रूपमा प्रयोगकर्ता व्यवहार (नमस्ते गैर-GDPR-अनुरूप सेवाहरू) बारे जानकारी सङ्कलन वा प्रयोग गर्न सक्छ वा अन्य अवैध गतिविधिहरूमा संलग्न हुन सक्छ।

धेरै अन्य अवस्थामा, यो अवस्थित तयार समाधान प्रयोग गर्न थप उपयुक्त छ।

के सुरु गर्न आवश्यक छ

यदि तपाईंसँग आफ्नै स्वायत्त प्रणाली (AS) छ भने यो अद्भुत छ। यसको साथ, तपाइँ धेरै सर्भरहरूमा समान आईपी प्रदान गर्न सक्नुहुन्छ र यस निर्देशन अनुसार नेटवर्क स्तरमा, प्रयोगकर्ताहरूलाई नजिकको एकमा प्रत्यक्ष गर्नुहोस्। यो भन्न लायक छ कि /24 ठेगाना ब्लक संग, यो एक सामग्री वितरण नेटवर्क निर्माण गर्न सम्भव छ। केही सर्भर प्रदायकहरूले तपाईंलाई तिनीहरूका लागि उपलब्ध सबै क्षेत्रहरूमा प्रयोगको लागि घोषणा गर्न अनुमति दिन्छ।

यदि तपाईं IP ठेगानाहरूको ब्लकको खुसी मालिक हुनुहुन्न भने, एक साधारण CDN चलाउन तपाईंलाई आवश्यक पर्दछ:

डोमेन नाम वा सबडोमेन
विभिन्न क्षेत्रहरूमा कम्तिमा दुई सर्भरहरू। सर्भर या त समर्पित वा भर्चुअल हुन सक्छ
geoDNS उपकरण। यसको साथ, प्रयोगकर्ता, डोमेनलाई सम्बोधन गरिसकेपछि, नजिकको सर्भरमा निर्देशित गरिनेछ

डोमेन दर्ता गर्नुहोस् र सर्भरहरू अर्डर गर्नुहोस्

डोमेन रेजिष्ट्रेसनको साथ, सबै कुरा सरल छ - हामी कुनै पनि रजिस्ट्रारसँग कुनै पनि क्षेत्रमा दर्ता गर्छौं। तपाइँ CDN को लागी सबडोमेन पनि प्रयोग गर्न सक्नुहुन्छ, उदाहरण को लागी केहि जस्तै cdn.domainname.com। वास्तवमा, हाम्रो उदाहरणमा, हामी त्यही गर्नेछौं।

सर्भरहरू अर्डर गर्नको लागि, तिनीहरू क्षेत्रहरू र देशहरूमा भाडामा लिनुपर्छ जहाँ तपाईंको प्रयोगकर्ता दर्शकहरू अवस्थित छन्। यदि परियोजना अन्तरमहाद्वीपीय छ भने, होस्टिङ प्रदायकहरू छनौट गर्न यो सुविधाजनक छ जुन एकैचोटि विश्वभर सर्भरहरू प्रस्ताव गर्दछ। उदाहरणहरू: Amazon.com, Inc, लीजवेब и १ टीबी - समर्पित सर्भरहरूको लागि, Vultr и डिजिटल ओसन - भर्चुअल क्लाउड * को लागी।

हाम्रो निजी CDN को लागि, हामी विभिन्न महादेशहरूमा 3 भर्चुअल सर्भरहरू अर्डर गर्नेछौं। मा Vultr को लागि सर्भरमा $५/महिना हामी प्राप्त गर्नेछौं 25GB SSD ठाउँ र ट्राफिकको 1TB। स्थापना गर्दा, नवीनतम डेबियन चयन गर्नुहोस्। हाम्रा सर्भरहरू:

फ्रैंकफर्ट, ip: 199.247.18.199

शिकागो, ip: 149.28.121.123

Сингапур, ip: 157.230.240.216

* Vultr र DigitalOcean ले भुक्तानी विधि थपेपछि लेखमा लिङ्कहरू मार्फत दर्ता गर्ने प्रयोगकर्ताहरूलाई $100 क्रेडिट दिने वाचा गर्दछ। यसबाट लेखकले पनि एउटा सानो प्रशंसा पाउँछन्, जुन उनको लागि अहिले धेरै महत्त्वपूर्ण छ। कृपया बुझ्नु होला।

GeoDNS सेटअप गर्दै

डोमेन वा CDN सबडोमेन पहुँच गर्दा प्रयोगकर्तालाई चाहिएको (नजिक) सर्भरमा निर्देशित गर्नको लागि, हामीलाई geoDNS प्रकार्य भएको DNS सर्भर चाहिन्छ।

geoDNS को सिद्धान्त र सञ्चालन निम्नानुसार छ:

DNS अनुरोध पठाउने क्लाइन्टको IP, वा क्लाइन्ट अनुरोध प्रशोधन गर्दा प्रयोग हुने पुनरावर्ती DNS सर्भरको IP निर्दिष्ट गर्दछ। त्यस्ता पुनरावर्ती सर्भरहरू प्राय: प्रदायकहरूको DNS-s हुन्।
ग्राहकको IP ले उसको देश वा क्षेत्र पहिचान गर्दछ। यसको लागि, GeoIP डाटाबेसहरू प्रयोग गरिन्छ, जसमध्ये आज धेरै धेरै छन्। राम्रा छन् नि: शुल्क विकल्पहरू.
ग्राहकको स्थानमा निर्भर गर्दै, उसलाई नजिकको CDN सर्भरको IP ठेगाना दिन्छ।

geoDNS प्रकार्यको साथ DNS सर्भर हुन सक्छ आफैं जम्मा गर्नुहोस्, तर संसारभरि र DNS सर्भरहरूको नेटवर्कको साथ तयार समाधानहरू प्रयोग गर्नु राम्रो हुन्छ कुनै पनि कास्ट बक्सबाट:

slouDNS देखि $५/महिना, GeoDNS ट्यारिफ, पूर्वनिर्धारित रूपमा त्यहाँ एक DNS फेलओभर छ
जिलोर देखि $५/महिना, DNS फेलओभर सक्षम गरियो
Amazon Route 53 देखि $५/महिना नेट 50M जियो-अनुरोधहरूको लागि। DNS फेलओभर छुट्टै बिल गरिन्छ
DNS सजिलो भयो देखि $५/महिना, त्यहाँ 10 DNS फेलओभरहरू छन्
Cloudflare, "जियो स्टीयरिङ" सुविधा इन्टरप्राइज योजनाहरूमा उपलब्ध छ

geoDNS अर्डर गर्दा, तपाईंले ट्यारिफमा समावेश गरिएका अनुरोधहरूको संख्यामा ध्यान दिनुपर्छ र डोमेनमा अनुरोधहरूको वास्तविक संख्या धेरै गुणाले अपेक्षाहरू भन्दा बढी हुन सक्छ भन्ने कुरामा ध्यान दिनुपर्छ। लाखौं माकुराहरू, स्क्यानरहरू, स्प्यामरहरू र अन्य दुष्ट आत्माहरू अथक रूपमा काम गर्छन्।

लगभग सबै DNS सेवाहरूमा CDN - DNS फेलओभर निर्माणको लागि अपरिहार्य सेवा समावेश छ। यसको मद्दतले, तपाइँ तपाइँको सर्भरहरूको सञ्चालनको अनुगमन सेट अप गर्न सक्नुहुन्छ र जीवनको संकेतहरूको अनुपस्थितिमा, स्वचालित रूपमा DNS प्रतिक्रियाहरूमा ब्याकअपको साथ गैर-काम गर्ने सर्भरको ठेगाना बदल्नुहोस्।

हाम्रो CDN निर्माण गर्न, हामी प्रयोग गर्नेछौं CloudDNS, GeoDNS ट्यारिफ।

तपाईको व्यक्तिगत खातामा तपाईको डोमेन निर्दिष्ट गर्दै नयाँ DNS क्षेत्र थपौं। यदि हामीले सबडोमेनमा CDN निर्माण गर्दैछौं, र मुख्य डोमेन पहिले नै प्रयोगमा छ भने, क्षेत्र थपेपछि तुरुन्तै अवस्थित कार्यरत DNS रेकर्डहरू थप्न नबिर्सनुहोस्। अर्को चरण भनेको CDN डोमेन / सबडोमेनका लागि धेरै A-रेकर्डहरू सिर्जना गर्नु हो, जसमध्ये प्रत्येक हामीले निर्दिष्ट गरेको क्षेत्रमा लागू हुनेछ। तपाईले महाद्वीप वा देशहरूलाई क्षेत्रको रूपमा निर्दिष्ट गर्न सक्नुहुन्छ, उप-क्षेत्रहरू संयुक्त राज्य अमेरिका र क्यानडाका लागि उपलब्ध छन्।

हाम्रो अवस्थामा, CDN उप-डोमेनमा उठाइनेछ cdn.sayt.in। क्षेत्र थपेर sayt.in, सबडोमेनको लागि पहिलो A-रेकर्ड सिर्जना गर्नुहोस् र शिकागोको सर्भरमा सम्पूर्ण उत्तर अमेरिकालाई देखाउनुहोस्:

पूर्वनिर्धारित क्षेत्रहरूको लागि एउटा प्रविष्टि सिर्जना गर्न सम्झँदै, अन्य क्षेत्रहरूको लागि कार्य दोहोर्याउनुहोस्। यहाँ अन्तमा के हुन्छ:

स्क्रिनसटमा अन्तिम पूर्वनिर्धारित प्रविष्टिको अर्थ सबै अनिर्दिष्ट क्षेत्रहरू (र यी युरोप, अफ्रिका, स्याटेलाइट इन्टरनेट प्रयोगकर्ताहरू, आदि हुन्) फ्र्याङ्कफर्टको सर्भरमा पठाइने छ।

यसले आधारभूत DNS सेटअप पूरा गर्छ। यो डोमेन रजिस्ट्रारको वेबसाइटमा जानुहोस् र हालको डोमेन NSs लाई CloudDNS द्वारा जारी गरिएकोसँग बदल्न बाँकी छ। र जब NSs अद्यावधिक हुनेछन्, हामी सर्भरहरू तयार गर्नेछौं।

SSL प्रमाणपत्रहरूको स्थापना

हाम्रो CDN ले HTTPS मा काम गर्नेछ, त्यसैले यदि तपाइँसँग पहिले नै डोमेन वा सबडोमेनको लागि SSL प्रमाणपत्रहरू छन् भने, तिनीहरूलाई सबै सर्भरहरूमा अपलोड गर्नुहोस्, उदाहरणका लागि, निर्देशिकामा। /etc/ssl/yourdomain/

यदि त्यहाँ कुनै प्रमाणपत्रहरू छैनन् भने, तपाईंले Let's Encrypt बाट नि:शुल्क प्राप्त गर्न सक्नुहुन्छ। यसका लागि उत्तम ACME शेलस्क्रिप्ट। क्लाइन्ट सुविधाजनक र सेटअप गर्न सजिलो छ, र सबैभन्दा महत्त्वपूर्ण कुरा, यसले तपाईंलाई CloudDNS API मार्फत DNS द्वारा डोमेन/सबडोमेन मान्य गर्न अनुमति दिन्छ।

हामी acme.sh लाई केवल एउटा सर्भरमा स्थापना गर्नेछौं - यूरोपीयन 199.247.18.199, जसबाट प्रमाणपत्रहरू अन्य सबैमा प्रतिलिपि गरिनेछ। स्थापना गर्न, चलाउनुहोस्:

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

स्क्रिप्टको स्थापनाको क्रममा, हाम्रो सहभागिता बिना प्रमाणपत्रहरूको थप नवीकरणको लागि CRON कार्य सिर्जना गरिनेछ।

प्रमाणपत्र जारी गर्दा, डोमेन API को प्रयोग गरेर DNS प्रयोग गरी जाँच गरिनेछ, त्यसैले पुनर्विक्रेता API मेनुमा CloudDNS व्यक्तिगत खातामा, तपाईंले नयाँ प्रयोगकर्ता 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"

विकल्पहरूमा, भविष्यको लागि, हामीले भविष्यमा प्रमाणपत्र वैधता अवधिको प्रत्येक नवीकरण पछि वेब सर्भर कन्फिगरेसन स्वचालित रूपमा पुन: लोड गर्न आदेश निर्दिष्ट गरेका छौं।

प्रमाणपत्र प्राप्त गर्ने सम्पूर्ण प्रक्रियाले २ मिनेटसम्म लिन सक्छ, यसलाई अवरोध नगर्नुहोस्। यदि डोमेन प्रमाणीकरण त्रुटि भयो भने, आदेश पुन: चलाउने प्रयास गर्नुहोस्। अन्तमा हामी हेर्नेछौं कि प्रमाणपत्रहरू कहाँ अपलोड गरिएका छन्:

यी मार्गहरू सम्झनुहोस्, तिनीहरू अन्य सर्भरहरूमा प्रमाणपत्र प्रतिलिपि गर्दा, साथै वेब सर्भर सेटिङहरूमा निर्दिष्ट गर्न आवश्यक हुनेछ। हामी 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। हाम्रो उदाहरणको साथ तिनीहरूलाई विश्लेषण गरौं। जब के हुन्छ यहाँ छ निष्क्रिय = 7d и proxy_cache_valid 90d:

यदि अनुरोध 7 दिन भित्र दोहोर्याइएको छैन भने, यस अवधि पछि डाटा क्यासबाट मेटिनेछ
यदि अनुरोध कम्तिमा प्रत्येक 7 दिनमा एक पटक दोहोर्याइएको छ भने, क्यासमा रहेको डाटा 90 दिन पछि अप्रचलित मानिनेछ र Nginx ले यसलाई अर्को अनुरोधको साथ अद्यावधिक गर्नेछ, यसलाई मूल सर्भरबाट लिनेछ।

सम्पादन गर्न सकियो nginx.conf, कन्फिगरेसन पुन: लोड गर्नुहोस्:

root@cdn:~# service nginx reload

हाम्रो CDN तयार छ। $15/महिनाको लागि। हामीले तीन महादेशहरूमा उपस्थितिको बिन्दुहरू र ट्राफिकको 3 TB प्राप्त गर्यौं: प्रत्येक स्थानमा 1 TB।

CDN को काम जाँच गर्दै

विभिन्न भौगोलिक स्थानहरूबाट हाम्रो CDN मा पिंगहरू हेरौं। कुनै पनि पिंग सेवा यसको लागि काम गर्नेछ।

लन्च बिन्दु
होस्ट
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 पोइन्टमा क्यास खाली गर्न चाहन्छौं भने एउटा सानो स्क्रिप्ट लेखौं।
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 फेलओभर कन्फिगर गर्न सिफारिस गरिन्छ, जसले सर्भर ब्रेकडाउनको घटनामा A रेकर्डलाई द्रुत रूपमा परिवर्तन गर्न मद्दत गर्दछ। यो डोमेनको नियन्त्रण प्यानल DNS रेकर्डहरूमा गरिन्छ।
फराकिलो भौगोलिक कभरेज भएका साइटहरूलाई निस्सन्देह ठूलो संख्यामा CDN चाहिन्छ, तर कट्टरपन्थी नबनौं। यदि तपाईंले 6-7 स्थानहरूमा सर्भरहरू राख्नुभयो भने प्रायः प्रयोगकर्ताले सशुल्क CDN को तुलनामा महत्त्वपूर्ण भिन्नता देख्ने छैन: युरोप, उत्तरी अमेरिका (पूर्व), उत्तर अमेरिका (पश्चिम), सिंगापुर, अष्ट्रेलिया, हङकङ वा जापान।
कहिलेकाहीँ होस्टरहरूले CDN उद्देश्यका लागि भाडामा लिइएका सर्भरहरूको प्रयोगलाई अनुमति दिँदैनन्। तसर्थ, यदि तपाइँ अचानक एक सेवाको रूपमा सामग्री डेलिभरी नेटवर्क तैनात गर्ने निर्णय गर्नुहुन्छ भने, पहिले नै विशेष होस्टिंग प्रदायकको नियमहरू पढ्न नबिर्सनुहोस्।
अन्वेषण गर्नुहोस् पानीमुनि संचार नक्शामहाद्वीपहरू कसरी जोडिएका छन् भनेर प्रतिनिधित्व गर्न र सामग्री डेलिभरी नेटवर्क निर्माण गर्दा यसलाई ध्यानमा राख्नुहोस्
जाँच गर्ने प्रयास गर्नुहोस् विभिन्न ठाउँबाट पिंगहरू तपाईंको सर्भरहरूमा। यस तरिकाले तपाईंले CDN बिन्दुहरूको नजिकका क्षेत्रहरू हेर्न सक्नुहुन्छ र GeoDNS थप सही रूपमा कन्फिगर गर्न सक्नुहुन्छ।
कार्यहरूमा निर्भर गर्दै, यो विशिष्ट क्यासिंग आवश्यकताहरूको लागि Nginx लाई फाइन-ट्यून गर्न र सर्भरमा लोडलाई ध्यानमा राख्न उपयोगी हुनेछ। Nginx क्यासको बारेमा लेखहरूले मलाई यसमा धेरै मद्दत गर्‍यो - यहाँ र भारी भार अन्तर्गत काम को गति: यहाँ и यहाँ