Prohoster > Blog > quản lý > Xây dựng và định cấu hình CDN của bạn

Xây dựng và định cấu hình CDN của bạn

Mạng phân phối nội dung (CDN) được sử dụng chủ yếu trong các trang web và ứng dụng để tăng tốc độ tải các phần tử tĩnh. Điều này xảy ra do việc lưu trữ các tệp trên máy chủ CDN nằm ở các khu vực địa lý khác nhau. Bằng cách yêu cầu dữ liệu qua CDN, người dùng sẽ nhận được dữ liệu từ máy chủ gần nhất.

Nguyên tắc hoạt động và chức năng của tất cả các mạng phân phối nội dung gần như giống nhau. Sau khi nhận được yêu cầu tải xuống một tệp, máy chủ CDN sẽ lấy tệp đó một lần từ máy chủ ban đầu và cung cấp cho người dùng, đồng thời lưu vào bộ nhớ đệm trong một khoảng thời gian xác định. Tất cả các yêu cầu tiếp theo được trả lời từ bộ đệm. Tất cả CDN đều có các tùy chọn tải trước tệp, xóa bộ nhớ đệm, đặt ngày hết hạn, v.v.

Điều đó xảy ra là, vì lý do này hay lý do khác, bạn cần tổ chức mạng lưới phân phối nội dung của riêng mình và sau đó - hãy để chúng tôi trợ giúp các hướng dẫn lắp ráp chiếc xe đạp tiếp theo.

Xây dựng và định cấu hình CDN của bạn
Nguồn: Vector đồ họa thông tin được tạo bởi pikisuperstar - www.freepik.com

Khi bạn cần CDN của riêng mình

Hãy xem xét các trường hợp việc chạy CDN của riêng bạn có ý nghĩa:

  • khi có mong muốn tiết kiệm tiền và chi phí vận hành ngay cả khi sử dụng CDN rẻ tiền như chú thỏCDN lên tới vài trăm đô la một tháng
  • nếu chúng tôi muốn có bộ đệm vĩnh viễn hoặc bộ đệm không có máy chủ và kênh lân cận
  • Dịch vụ CDN chưa có điểm hiện diện tại khu vực bạn cần
  • bất kỳ cài đặt phân phối nội dung đặc biệt nào được yêu cầu
  • chúng tôi muốn tăng tốc độ phân phối nội dung động bằng cách đặt máy chủ sản xuất gần hơn với người dùng
  • có lo ngại rằng dịch vụ CDN của bên thứ ba có thể thu thập hoặc sử dụng bất hợp pháp thông tin về hành vi của người dùng (xin chào các dịch vụ không tuân thủ GDPR) hoặc tham gia vào các hoạt động bất hợp pháp khác

Trong hầu hết các trường hợp khác, sẽ phù hợp hơn khi sử dụng các giải pháp làm sẵn hiện có.

Bạn cần gì để bắt đầu

Thật tuyệt vời nếu bạn có Hệ thống tự trị (AS) của riêng mình. Với nó, bạn có thể gán cùng một IP cho nhiều máy chủ và theo hướng dẫn này ở cấp độ mạng, hướng người dùng đến mạng gần nhất. Điều đáng nói là ngay cả với khối địa chỉ /24, vẫn có thể xây dựng mạng phân phối nội dung. Một số nhà cung cấp máy chủ cho phép bạn đưa ra thông báo để sử dụng ở tất cả các khu vực có sẵn cho họ.

Nếu bạn không phải là chủ sở hữu hài lòng của một khối địa chỉ IP thì để chạy CDN đơn giản, bạn sẽ cần:

  • tên miền hoặc tên miền phụ
  • ít nhất hai máy chủ ở các khu vực khác nhau. Máy chủ có thể là máy chủ chuyên dụng hoặc ảo
  • công cụ geoDNS. Với nó, người dùng sau khi đánh địa chỉ tên miền sẽ được chuyển hướng đến máy chủ gần nhất

Đăng ký tên miền và đặt hàng máy chủ

Với đăng ký tên miền, mọi thứ đều đơn giản - chúng tôi đăng ký ở bất kỳ khu vực nào với bất kỳ nhà đăng ký nào. Bạn cũng có thể sử dụng tên miền phụ cho CDN, ví dụ như cdn.domainname.com. Trên thực tế, trong ví dụ của chúng tôi, chúng tôi sẽ làm điều đó.

Đối với việc đặt hàng máy chủ, chúng nên được thuê ở các khu vực và quốc gia nơi có đối tượng người dùng của bạn. Nếu dự án mang tính xuyên lục địa thì sẽ thuận tiện hơn khi chọn các nhà cung cấp dịch vụ lưu trữ cung cấp máy chủ trên toàn thế giới cùng một lúc. Ví dụ: OVH, Cho thuê web и 100Tb - dành cho máy chủ chuyên dụng, Vultr и DigitalOcean — dành cho đám mây ảo*.

Đối với CDN riêng của chúng tôi, chúng tôi sẽ đặt hàng 3 máy chủ ảo ở các châu lục khác nhau. Tại Vultr trên máy chủ cho $5/tháng chúng ta sẽ lấy 25GB SSD địa điểm và 1TB lưu lượng. Khi cài đặt, hãy chọn Debian mới nhất. Máy chủ của chúng tôi:

Xây dựng và định cấu hình CDN của bạn Frankfurt, ip: 199.247.18.199

Xây dựng và định cấu hình CDN của bạn Chicago, ip: 149.28.121.123

Xây dựng và định cấu hình CDN của bạn Singapore, ip: 157.230.240.216

* Vultr và DigitalOcean hứa hẹn khoản tín dụng 100 USD cho người dùng đăng ký qua các liên kết trong bài viết ngay sau khi thêm phương thức thanh toán. Tác giả cũng nhận được một lời khen nhỏ từ điều này, điều này rất có ý nghĩa đối với anh lúc này. Xin hãy hiểu biết.

Thiết lập GeoDNS

Để người dùng được dẫn đến máy chủ mong muốn (gần nhất) khi truy cập một tên miền hoặc tên miền phụ CDN, chúng ta cần một máy chủ DNS có chức năng geoDNS.

Nguyên lý và hoạt động của GeoDNS như sau:

  1. Chỉ định IP của máy khách đã gửi yêu cầu DNS hoặc IP của máy chủ DNS đệ quy được sử dụng khi xử lý yêu cầu của máy khách. Các máy chủ đệ quy như vậy thường là DNS của các nhà cung cấp.
  2. IP của khách hàng nhận dạng quốc gia hoặc khu vực của mình. Đối với điều này, cơ sở dữ liệu GeoIP được sử dụng, trong đó có rất nhiều cơ sở dữ liệu ngày nay. có tốt tùy chọn miễn phí.
  3. Tùy thuộc vào vị trí của khách hàng, cung cấp cho anh ta địa chỉ IP của máy chủ CDN gần nhất.

Máy chủ DNS có chức năng GeoDNS có thể tự lắp ráp, nhưng tốt hơn hết bạn nên sử dụng các giải pháp có sẵn với mạng lưới máy chủ DNS trên toàn thế giới và phát sóng bất kỳ từ chiếc hộp:

  • CloudDNS từ $9.95/tháng, biểu giá GeoDNS, theo mặc định có một Chuyển đổi dự phòng DNS
  • Zilore từ $25/tháng, Đã bật chuyển đổi dự phòng DNS
  • Amazon Route 53 từ $35/tháng cho 50 triệu yêu cầu địa lý ròng. Chuyển đổi dự phòng DNS được tính phí riêng
  • DNS trở nên dễ dàng từ $125/tháng, có 10 lỗi DNS
  • CloudFlare, tính năng "Chỉ đạo địa lý" có sẵn trong gói Enterprise

Khi đặt hàng GeoDNS, bạn nên chú ý đến số lượng yêu cầu có trong biểu giá và lưu ý rằng số lượng yêu cầu thực tế đối với miền có thể vượt quá mong đợi nhiều lần. Hàng triệu con nhện, máy quét, kẻ gửi thư rác và những linh hồn ma quỷ khác làm việc không mệt mỏi.

Hầu như tất cả các dịch vụ DNS đều bao gồm một dịch vụ không thể thiếu để xây dựng CDN – DNS Failover. Với sự trợ giúp của nó, bạn có thể thiết lập giám sát hoạt động của máy chủ của mình và trong trường hợp không có dấu hiệu hoạt động, hãy tự động thay thế địa chỉ của máy chủ không hoạt động bằng địa chỉ dự phòng trong phản hồi DNS.

Để xây dựng CDN, chúng tôi sẽ sử dụng đám mâyDNS, biểu giá GeoDNS.

Hãy thêm vùng DNS mới trong tài khoản cá nhân của bạn, chỉ định tên miền của bạn. Nếu chúng tôi đang xây dựng CDN trên tên miền phụ và tên miền chính đã được sử dụng thì ngay sau khi thêm vùng, đừng quên thêm các bản ghi DNS đang hoạt động hiện có. Bước tiếp theo là tạo một số bản ghi A cho miền/miền phụ CDN, mỗi bản ghi đó sẽ được áp dụng cho vùng mà chúng ta đã chỉ định. Bạn có thể chỉ định các châu lục hoặc quốc gia làm vùng, các tiểu vùng có sẵn cho Hoa Kỳ và Canada.

Trong trường hợp của chúng tôi, CDN sẽ được nâng lên trên một tên miền phụ cdn.sayt.in. Bằng cách thêm một vùng sayt.in, tạo bản ghi A đầu tiên cho tên miền phụ và trỏ toàn bộ Bắc Mỹ đến máy chủ ở Chicago:

Xây dựng và định cấu hình CDN của bạn
Hãy lặp lại hành động này cho các vùng khác, nhớ tạo một mục nhập cho các vùng mặc định. Đây là những gì xảy ra cuối cùng:

Xây dựng và định cấu hình CDN của bạn

Mục nhập mặc định cuối cùng trong ảnh chụp màn hình có nghĩa là tất cả các khu vực không xác định (và đây là Châu Âu, Châu Phi, người dùng Internet vệ tinh, v.v.) sẽ được gửi đến máy chủ ở Frankfurt.

Điều này hoàn thành việc thiết lập DNS cơ bản. Vẫn phải truy cập trang web của nhà đăng ký tên miền và thay thế NS tên miền hiện tại bằng NS tên miền do CloudDNS cấp. Và trong khi NS sẽ được cập nhật, chúng tôi sẽ chuẩn bị máy chủ.

Cài đặt chứng chỉ SSL

CDN của chúng tôi sẽ hoạt động qua HTTPS, vì vậy nếu bạn đã có chứng chỉ SSL cho một miền hoặc miền phụ, hãy tải chúng lên tất cả các máy chủ, chẳng hạn như vào thư mục /etc/ssl/yourdomain/

Nếu không có chứng chỉ, bạn có thể nhận một chứng chỉ miễn phí từ Let's Encrypt. Hoàn hảo cho việc này Bản thảo ACME. Ứng dụng khách này thuận tiện và dễ cài đặt và quan trọng nhất là nó cho phép bạn xác thực tên miền/tên miền phụ bằng DNS thông qua API CloudDNS.

Chúng tôi sẽ chỉ cài đặt acme.sh trên một trong các máy chủ - Châu Âu 199.247.18.199, từ đó các chứng chỉ sẽ được sao chép sang tất cả các máy chủ khác. Để cài đặt, hãy chạy:

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

Trong quá trình cài đặt tập lệnh, một công việc CRON sẽ được tạo để gia hạn thêm chứng chỉ mà không có sự tham gia của chúng tôi.

Khi cấp chứng chỉ, miền sẽ được kiểm tra bằng DNS bằng API, vì vậy trong tài khoản cá nhân CloudDNS trong menu Reseller API, bạn cần tạo API người dùng mới và đặt mật khẩu cho nó. ID xác thực kết quả có mật khẩu sẽ được ghi vào tệp ~/.acme.sh/dnsapi/dns_cloudns.sh (đừng nhầm với tập tin dns_clouddns.sh). Dưới đây là những dòng cần được bỏ ghi chú và chỉnh sửa:

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

Bây giờ chúng tôi sẽ yêu cầu chứng chỉ SSL cho cdn.sayt.in

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

Trong các tùy chọn, trong tương lai, chúng tôi đã chỉ định một lệnh để tự động tải lại cấu hình máy chủ web sau mỗi lần gia hạn thời hạn hiệu lực của chứng chỉ trong tương lai.

Toàn bộ quá trình lấy chứng chỉ có thể mất tới 2 phút, đừng làm gián đoạn quá trình này. Nếu xảy ra lỗi xác thực tên miền, hãy thử chạy lại lệnh. Cuối cùng chúng ta sẽ thấy nơi các chứng chỉ đã được tải lên:

Xây dựng và định cấu hình CDN của bạn

Hãy nhớ những đường dẫn này, chúng sẽ cần được chỉ định khi sao chép chứng chỉ sang các máy chủ khác, cũng như trong cài đặt máy chủ web. Chúng tôi không chú ý đến lỗi tải lại cấu hình Nginx - nó sẽ không có trên máy chủ được cấu hình đầy đủ khi cập nhật chứng chỉ.

Tất cả những gì chúng tôi còn lại cho SSL là sao chép chứng chỉ đã nhận sang hai máy chủ khác trong khi vẫn duy trì đường dẫn đến tệp. Hãy tạo các thư mục giống nhau trên mỗi thư mục và tạo một bản sao:

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/

Để cập nhật chứng chỉ thường xuyên, hãy tạo công việc CRON hàng ngày trên cả hai máy chủ bằng lệnh:

scp -r [email protected]:/root/.acme.sh/cdn.sayt.in/* /root/.acme.sh/cdn.sayt.in/ && service nginx reload

Trong trường hợp này, quyền truy cập vào máy chủ nguồn từ xa phải được cấu hình bằng chìa khóa, I E. mà không cần nhập mật khẩu. Đừng quên làm điều đó.

Cài đặt và cấu hình Nginx

Để phục vụ nội dung tĩnh, chúng tôi sẽ sử dụng Nginx được định cấu hình làm máy chủ proxy bộ nhớ đệm. Cập nhật danh sách gói và cài đặt nó trên cả ba máy chủ:

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

Thay vì mặc định, chúng tôi sử dụng cấu hình từ spoiler bên dưới:
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;
    }
  }
}

Chỉnh sửa trong cấu hình:

  • kích thước tối đa - kích thước của bộ đệm, không vượt quá dung lượng đĩa trống
  • không hoạt động - thời gian lưu trữ dữ liệu được lưu trong bộ nhớ cache mà không ai truy cập
  • ssl_certificate и ssl_certificate_key - đường dẫn đến chứng chỉ SSL và các tệp chính
  • proxy_cache_valid - thời gian lưu trữ dữ liệu được lưu trữ
  • proxy_pass — địa chỉ của máy chủ ban đầu mà CDN sẽ yêu cầu các tệp để lưu vào bộ nhớ đệm. Trong ví dụ của chúng tôi, điều này sayt.in

Như bạn có thể thấy, mọi thứ đều đơn giản. Khó khăn chỉ có thể phát sinh trong việc thiết lập thời gian lưu vào bộ đệm do sự giống nhau của các chỉ thị không hoạt động и proxy_cache_valid. Hãy phân tích chúng với ví dụ của chúng tôi. Đây là những gì xảy ra khi không hoạt động=7ngày и proxy_cache_valid 90d:

  • nếu yêu cầu không được lặp lại trong vòng 7 ngày thì dữ liệu sẽ bị xóa khỏi bộ đệm sau khoảng thời gian này
  • nếu yêu cầu được lặp lại ít nhất 7 ngày một lần thì dữ liệu trong bộ đệm sẽ bị coi là lỗi thời sau 90 ngày và Nginx sẽ cập nhật nó với yêu cầu tiếp theo, lấy dữ liệu từ máy chủ ban đầu

Đã chỉnh sửa xong nginx.conf, tải lại cấu hình:

root@cdn:~# service nginx reload

CDN của chúng tôi đã sẵn sàng. Với giá $15/tháng. chúng tôi đã nhận được các điểm hiện diện trên ba lục địa và 3 TB lưu lượng: 1 TB ở mỗi địa điểm.

Kiểm tra hoạt động của CDN

Hãy xem các ping tới CDN của chúng tôi từ các vị trí địa lý khác nhau. Bất kỳ dịch vụ ping nào cũng sẽ hoạt động cho việc này.

Điểm phóng
Tổ chức
IP
Thời gian trung bình, ms

nước ĐứcBerlin
cdn.sayt.in
199.247.18.199
9.6

Hà Lan, Amsterdam
cdn.sayt.in
199.247.18.199
10.1

Pháp Paris
cdn.sayt.in
199.247.18.199
16.3

Vương quốc Anh, Luân Đôn
cdn.sayt.in
199.247.18.199
14.9

Canada, Toronto
cdn.sayt.in
149.28.121.123
16.2

Hoa Kỳ, San Francisco
cdn.sayt.in
149.28.121.123
52.7

Hoa Kỳ, Dallas
cdn.sayt.in
149.28.121.123
23.1

Hoa Kỳ, Chicago
cdn.sayt.in
149.28.121.123
2.6

Hoa Kỳ, New York
cdn.sayt.in
149.28.121.123
19.8

Singapore
cdn.sayt.in
157.230.240.216
1.7

Nhật BảnTokyo
cdn.sayt.in
157.230.240.216
74.8

Úc, Sydney
cdn.sayt.in
157.230.240.216
95.9

Kết quả là tốt. Bây giờ chúng ta sẽ đặt một hình ảnh thử nghiệm vào thư mục gốc của trang web chính test.jpg và kiểm tra tốc độ tải xuống qua CDN. Người ta nói - thực hiện. Nội dung được phân phối nhanh chóng.

Hãy viết một đoạn script nhỏ trong trường hợp chúng ta muốn xóa bộ đệm trên điểm CDN.
thanh trừng.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

Để xóa toàn bộ bộ đệm, chỉ cần chạy nó, một tệp riêng biệt có thể được xóa như thế này:

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

Thay vì kết luận

Cuối cùng, tôi muốn đưa ra một số lời khuyên hữu ích để có thể bước qua ngay cái cào khiến tôi đau đầu lúc đó:

  • Để tăng khả năng chịu lỗi của CDN, nên cấu hình DNS Failover, giúp thay đổi nhanh bản ghi A trong trường hợp máy chủ gặp sự cố. Điều này được thực hiện trong bảng điều khiển bản ghi DNS của tên miền.
  • Các trang web có phạm vi địa lý rộng chắc chắn sẽ yêu cầu số lượng lớn CDN, nhưng đừng cuồng tín. Nhiều khả năng người dùng sẽ không nhận thấy sự khác biệt đáng kể so với CDN trả phí nếu bạn đặt máy chủ ở 6-7 địa điểm: Châu Âu, Bắc Mỹ (phía đông), Bắc Mỹ (tây), Singapore, Úc, Hồng Kông hoặc Nhật Bản
  • Đôi khi các nhà cung cấp dịch vụ lưu trữ không cho phép sử dụng máy chủ thuê cho mục đích CDN. Do đó, nếu bạn đột nhiên quyết định triển khai mạng phân phối nội dung dưới dạng dịch vụ, đừng quên đọc trước các quy tắc của một nhà cung cấp dịch vụ lưu trữ cụ thể
  • Khám phá bản đồ thông tin liên lạc dưới nướcđể thể hiện cách các lục địa được kết nối và tính đến điều này khi xây dựng mạng phân phối nội dung
  • Hãy thử kiểm tra ping từ những nơi khác nhau tới máy chủ của bạn. Bằng cách này bạn có thể thấy các vùng gần điểm CDN nhất và định cấu hình GeoDNS chính xác hơn
  • Tùy thuộc vào nhiệm vụ, sẽ rất hữu ích khi tinh chỉnh Nginx cho các yêu cầu bộ nhớ đệm cụ thể và có tính đến tải trên máy chủ. Các bài viết về Nginx cache đã giúp tôi rất nhiều trong việc này - đây và tăng tốc làm việc dưới tải nặng: đây и đây

Nguồn: www.habr.com