Tôi đoán bạn đang đề cập đến cái này thiết lập DNS shopify.
điểm Một ghi vào địa chỉ IP của Shopify 23.227.38.65.
điểm CNAME ghi lại với tên www đến shop.myshopify.com
tên miền gốc (@)
Như bạn đã biết, bạn không thể có CNAME trên thư mục gốc (@) tên miền, vì vậy tên miền gốc cần được xử lý bằng một Một và AAAA các bản ghi trỏ vào các địa chỉ IP cố định.
Cách các công ty lớn mở rộng quy mô này trên toàn cầu là sử dụng "anycast" trong đó cùng một địa chỉ IP được công bố qua BGP từ nhiều trung tâm dữ liệu khác nhau.
Bạn có thể coi anycast là cân bằng tải được xử lý bởi các bộ định tuyến nơi nhiều máy chủ trong cùng một hoặc các trung tâm dữ liệu khác nhau có thể nhận và xử lý lưu lượng truy cập cho một địa chỉ IP.
Nếu bạn chưa phải là AS với không gian IP của riêng mình, thì anycast chắc chắn nằm ngoài phạm vi của bạn.
Cách đơn giản để bắt đầu ở đây là không chạy bất kỳ dịch vụ lưu trữ nào trên tên miền gốc mà chỉ thực hiện chuyển hướng đến www. Sau đó, một hộp chuyển hướng nginx duy nhất (hoặc nhiều hộp phía sau bộ cân bằng tải cấp 4/tcp) có thể xử lý khá nhiều chuyển hướng tên miền.
Nếu bạn cần nhiều hộp do số lượng yêu cầu lớn, hãy sử dụng cân bằng tải tcp/layer4 cho máy chủ chuyển hướng của bạn để bạn có thể chấm dứt ứng dụng (http) và ssl trên các hộp phía sau bộ cân bằng tải để có nhiều khả năng mở rộng hơn (bộ cân bằng tải đơn có thể xử lý nhiều lưu lượng hơn).
Sử dụng chuyển hướng vĩnh viễn (301) mà bộ nhớ cache vô thời hạn giảm lưu lượng truy cập định kỳ từ cùng một khách hàng.
thực hành tốt nhất ở đây. Sử dụng letsencrypt/certbot để tự động tạo/gia hạn miền chuyển hướng sau khi DNS được thiết lập. Luôn chuyển hướng đến https trên cùng một tên miền (ví dụ. http://example.com -> https://example.com) trước khi chuyển hướng đến một tên miền khác (https://www.example.com).
www
Nhìn vào shopify shop.myshopify.com (ở đâu www CNAME nên trỏ) bạn có thể thấy nó có một Một kỷ lục hiện tại 23.227.38.74.
Sử dụng một công cụ ping toàn cầu bạn có thể thấy rằng IP này có độ trễ vài mili giây từ nhiều nơi trên thế giới. Điều này có nghĩa là nó chắc chắn không phải là một máy chủ duy nhất ở một địa điểm (độ trễ xuyên Đại Tây Dương thường chạy 60 mili giây trong trường hợp tốt nhất...vì vậy khi bạn thấy ping 4 mili giây từ Hoa Kỳ và EU cho cùng một IP...bạn biết những ping đó không phải là ' không đi đến cùng một máy chủ). Bạn cũng có thể xác minh điều này bằng cách chạy theo dõi tới cùng một IP từ các máy chủ khác nhau ở các vùng địa lý khác nhau.
Tại mỗi điểm cuối của họ phản hồi IP đó, họ có thể có bộ cân bằng tải định tuyến các yêu cầu đến phần cứng khác nhau.
Vì vậy, đằng sau CNAME shopify, nó là một IP bất kỳ. Ưu điểm của việc cung cấp cho khách hàng của bạn một CNAME là bạn có quyền tự do thay đổi (các) IP đằng sau tên đó mà khách hàng của bạn không cần phải cập nhật DNS ở phía cuối. Lưu ý rằng... khi bạn cung cấp cho khách hàng của mình một Một bản ghi gốc của chúng (@) bộ chuyển hướng tên miền... bạn muốn đảm bảo đây là địa chỉ IP mà bạn có thể kiểm soát và gán lại cho phần cứng khác nếu bạn gặp sự cố với máy chủ/bộ cân bằng tải (ví dụ: loại IP đàn hồi AWS hoặc không gian IP của riêng bạn nếu bạn là AS).
Theo như tôi biết, không có bất kỳ "gợi ý" nào được đưa ra đối với yêu cầu DNS (và một phần của bộ nhớ đệm của trình phân giải DNS) khi máy tính của bạn tuân theo chuỗi CNAME khi phân giải tên để báo cho máy chủ DNS cuối cùng tên miền ban đầu là gì mà bạn đã yêu cầu. Nếu có thì bạn có thể tưởng tượng một máy chủ DNS có các quy tắc có điều kiện để trả về các địa chỉ IP khác nhau cho cùng một tên tùy thuộc vào tên đằng sau nó.
Vì vậy, nếu bạn không làm theo cách của shopify (bgp/anycast). Điều đơn giản nhất sẽ là cung cấp cho khách hàng của bạn CNAME duy nhất. Bằng cách này, bạn có thể thực hiện cân bằng tải ở cấp độ DNS (trả về các IP khác nhau cho mỗi CNAME khách hàng duy nhất).
Bạn có thể làm theo một số quy ước như tên miền khách hàng.tld.example.com và tự động cung cấp DNS dựa trên cơ sở dữ liệu về tài sản khách hàng của bạn.
Và đối với tên miền gốc (@), bạn vẫn có thể sử dụng một IP chuyển hướng duy nhất (một hoặc nhiều hộp phía sau một IP/bộ cân bằng tải) quản lý chuyển hướng cho tất cả các miền tới www.customerdomain.tld CNAME nào để tên miền khách hàng.tld.example.com.
Cập nhật... có thể tôi đã bỏ lỡ điểm chính trong câu hỏi của bạn.
Điều này sẽ giúp ích rất nhiều khi tôi cần di chuyển nhiều trang web sang cơ sở hạ tầng mới
Như tôi đã đề cập ở trên, ít nhất là đối với thư mục gốc/@ trường hợp, bạn CẦN kiểm soát IP đó và có thể gán nó cho cơ sở hạ tầng khác...nếu không, tất cả khách hàng của bạn sẽ phải cập nhật DNS của họ khi IP đó thay đổi do di chuyển.
Đối với www/CNAME trường hợp này không phải là vấn đề vì bạn chỉ có thể cập nhật IP đằng sau CNAME trên DNS của riêng mình.
Vì vậy, tôi sẽ chỉ tập trung vào các tùy chọn cho miền gốc (@) vì đó là vấn đề nghiêm trọng nhất (yêu cầu hành động của khách hàng là cập nhật DNS khi địa chỉ IP của dịch vụ của họ thay đổi). Tùy chọn...
tùy chọn 0 - không hỗ trợ root/@ tên miền cho khách hàng
Bất cứ điều gì bạn đang lưu trữ, hãy lưu trữ nó trên một tên miền phụ (www hoặc khác).
Nếu khách hàng muốn chuyển hướng, họ có thể quản lý điều đó ở cuối cùng với nhân viên CNTT của họ.
Điều này loại bỏ hoàn toàn DNS của khách hàng trỏ vào sự cố địa chỉ IP cố định. Bạn có thể cập nhật (các) địa chỉ IP CNAME ở phía mình và mọi hoạt động di chuyển cơ sở hạ tầng hoặc thay đổi IP đều trở nên đơn giản.
tùy chọn 1 - địa chỉ IP có thể gán
Bạn có thể sử dụng những thứ như địa chỉ IP có thể gán (loại ip linh hoạt của AWS, hầu hết các nhà cung cấp VPS nghiêm túc đều cung cấp thứ gì đó tương tự).
Điều này cho phép bạn triển khai một máy chủ mới (tại nhà cung cấp đó) và sau đó chuyển IP sang máy chủ mới.
Vấn đề là bạn đã khóa nhà cung cấp/nhà cung cấp vì địa chỉ IP thuộc về nhà cung cấp. Vì vậy, nếu bạn muốn chuyển từ AWS sang Google-Cloud hoặc phần cứng của riêng bạn, bạn không thể mang theo các IP đó bên mình.... Bản cập nhật DNS cho khách hàng của bạn. Ngoài ra, các IP có thể bị khóa vùng nên bạn không thể dễ dàng gán IP cho một máy chủ khác tại nhà cung cấp ở một trung tâm dữ liệu khác.
tùy chọn 2 - trở thành AS và nhận không gian IP của riêng bạn
Nếu bạn đang làm dịch vụ lưu trữ nghiêm túc, thì vấn đề chỉ là thời gian trước khi bạn cần trở thành một AS (Hệ thống tự trị) qua ARIN hoặc chín muồi hoặc một tổ chức khác nếu công ty của bạn ở bên ngoài Bắc Mỹ và Châu Âu.
Sau đó, bạn cần có (hoặc thuê) khối địa chỉ IP của riêng mình. Bạn có thể nhận được ipv6 miễn phí thường xuyên. ipv4 đã hết nhưng ít nhất RIPE cho phép bạn có tên trong danh sách chờ /24 (256 địa chỉ) khi họ phục hồi chúng theo thời gian. Nếu không, bạn phải mua không gian địa chỉ từ ai đó (có những thị trường mà bạn có thể tham gia).
Và tất nhiên sau đó bạn cần phải làm việc với các nhà cung cấp cho phép bạn mang địa chỉ IP của riêng mình.
Dưới đây là một số liên kết thực tế đi qua thiết lập anycast. Nhưng đối với người mới bắt đầu, hãy bỏ qua các bit anycast và tập trung vào việc thiết lập dưới dạng AS, nhận không gian IP và tìm loại đối tác hạ tầng phù hợp. (Bởi vì việc chạy BGP/anycast không hề đơn giản.)
Nhược điểm:
- đầu tư thời gian để thiết lập và tìm hiểu mọi thứ (ví dụ: BGP nếu nhà cung cấp ngược dòng của bạn không xử lý việc đó cho bạn).
- đầu tư tài chính (phí thành viên/IP cho RIPE/ARIN và chi phí tiềm năng lớn để mua/thuê các khối IPv4).
- giới hạn làm việc với các nhà cung cấp VPS cho phép bạn mang IP của riêng mình
- Hoặc bạn phải thuê không gian giá đỡ và đối phó với peering/routing/switching/BGP/etc, lỗi phần cứng, giám sát phần cứng SNMP, v.v.
- những phiền nhiễu mới như cần vé và giải quyết các khiếu nại lạm dụng liên quan đến không gian IP của bạn
Chắc chắn có ý nghĩa ở một quy mô nhất định hoặc nếu bạn đã có sẵn các kỹ năng và công cụ để quản lý nó.
tùy chọn 3 - DNS không chuẩn
Một số nhà cung cấp DNS được quản lý đã thêm CNAME-like hỗ trợ cho tên miền trần/gốc.
Nếu bạn sử dụng một trong những nhà cung cấp này hoặc tự triển khai điều này nếu bạn chạy DNS của riêng mình... thì điều đó có thể giải quyết được sự cố.
Xem câu trả lời này
Nếu bạn dựa vào điều này, thì bạn bị khóa bởi nhà cung cấp DNS hỗ trợ tính năng không chuẩn này. Hoặc bạn cần chạy DNS của riêng mình và tự thực hiện điều này.
tùy chọn 4 - CDN
Tùy thuộc vào ứng dụng của bạn, bạn có thể đặt một dịch vụ khác trước ứng dụng đó. tức là dịch vụ giống CDN (stackpath, cloudflare, aws-cloudfront, v.v.). Những người đó sẽ xử lý DNS/anycast và các chủ đề liên quan và bạn có thể yêu cầu khách hàng của mình chỉ vào dịch vụ CDN và chạy các dịch vụ của bạn đằng sau CDN.
Thay đổi dịch vụ back-end trở thành thay đổi cấu hình tại CDN (hoặc tương tự) để cho CDN biết tên/ip của điểm cuối của bạn mà nội dung sẽ được yêu cầu từ đó.
Nhược điểm:
- chi phí bổ sung nếu bạn không cần nó.
- cần đảm bảo các điểm cuối được lưu trong bộ nhớ cache và không được lưu trong bộ nhớ cache (ví dụ: ứng dụng) được định cấu hình trên CDN để khớp với cách (các) ứng dụng của bạn hoạt động.
- lớp bổ sung cần được gỡ lỗi nếu ứng dụng của bạn không hoạt động (CDN đã phá vỡ yêu cầu hay ứng dụng của bạn đã làm vậy?).
- thông thường, điều này có nghĩa là bản ghi CNAME của khách hàng của bạn sẽ trỏ đến miền của CDN...không phải của bạn. Miền của bạn nằm trong cấu hình của ứng dụng CDN dưới dạng máy chủ ngược dòng. Vì vậy, bạn đã khóa nhà cung cấp...nếu bạn muốn chuyển đổi CDN, tất cả khách hàng của bạn sẽ cần cập nhật CNAME DNS của họ để trỏ đến CDN mới. Bạn có thể giảm thiểu điều này bằng cách đặt 2 lớp CNAME (khách hàng -> bạn -> CDN) nhưng điều đó không tốt từ một quan điểm hiệu suất.
tôi sẽ làm gì
Nếu không có thêm thông tin chi tiết về quy mô, kỹ năng cơ sở khách hàng của bạn (ví dụ: BGP), cho dù bạn đang chạy phần cứng riêng hay thuê VPS giá rẻ...
Tôi thích đơn giản, bạn luôn có thể làm cho nó phức tạp hơn sau. Điều đơn giản nhất giúp tôi giảm chi phí, không tốn nhiều thời gian, tạo ra trải nghiệm người dùng tốt cho khách hàng của tôi và cuối cùng cho phép tôi quay lại các hoạt động tạo doanh thu (thay vì dành thời gian cho phụ trợ kỹ thuật mà có chi phí thời gian/tài chính với hy vọng giảm tổng chi phí theo quy mô). Tôi không phải là google, vì vậy tôi muốn phát triển doanh thu hàng đầu của mình hơn là tối ưu hóa vi mô lợi nhuận của mình...đặc biệt nếu (chưa) có nhu cầu kỹ thuật.
Tôi sẽ làm như sau ...
- không hỗ trợ cho tên miền trần/gốc của khách hàng. khách hàng muốn chuyển hướng có thể yêu cầu nhân viên CNTT của họ thiết lập chuyển hướng đó. Một cơn đau đầu ít hơn.
- Hoặc nếu bạn muốn hỗ trợ điều này thì bạn thiết lập một IP chuyển hướng duy nhất mà bạn biết rằng mình sẽ không bị mất (ví dụ: AWS đàn hồi IP) và yêu cầu khách hàng thiết lập
Một và AAAA Hồ sơ. Phần còn lại của các dịch vụ của bạn không cần phải được lưu trữ ở cùng một nơi (tức là bộ chuyển hướng có thể là AWS với ELB nếu bạn cần chuyển hướng theo quy mô và các hộp khách hàng có thể có trên các VPS giá rẻ).
- mỗi khách hàng nhận được một CNAME có thể dự đoán (duy nhất cho họ) dựa trên miền được lưu trữ hoặc ID khách hàng của họ (
CUS1234.example.com sẽ hợp lý hơn nếu bạn cung cấp cho khách hàng khả năng dễ dàng thay đổi miền mà họ lưu trữ).
- DNS của tôi được cập nhật tự động dựa trên cơ sở dữ liệu khách hàng của tôi (miền của khách hàng -> CNAME dành riêng cho khách hàng -> địa chỉ IP lưu trữ ứng dụng của khách hàng).
- Tôi có thể dễ dàng theo dõi DNS của khách hàng đó và tất cả DNS của tôi đều trỏ đến đúng nơi.
- Tôi có thể giám sát lưu lượng truy cập/lạm dụng DNS trên cơ sở từng khách hàng một cách riêng biệt (vì họ có tên duy nhất) từ điểm cuối của khách hàng.
Khách hàng đặt DNS một lần và không bao giờ cần thay đổi trừ khi họ muốn thay đổi tên miền được lưu trữ của mình.
Di chuyển cơ sở hạ tầng tương đối dễ dàng nếu bạn có các cơ chế sao lưu/khôi phục/sao chép tốt, hoạt động song song với một số hình thức khám phá dịch vụ trên lớp cung cấp máy chủ/vps/ứng dụng của bạn.
- đặt TTL DNS thấp trên các bản ghi DNS của bạn (tức là tên mà CNAME của khách hàng trỏ tới
CUST1234.example.com MỘT 10.0.0.1) một thời gian trước khi di chuyển.
- Tạo cơ sở hạ tầng mới bao gồm sao chép dữ liệu từ cơ sở hạ tầng cũ (cơ sở dữ liệu, nội dung do người dùng tải lên, v.v.).
- Chuyển bản ghi DNS khách hàng của bạn (
Một, AAAA) để trỏ đến các IP mới
- Gỡ bỏ cơ sở hạ tầng cũ sau khi DNS TTL + margin đã trôi qua.
Nếu chương trình phụ trợ dữ liệu của bạn không thể xử lý việc ghi từ 2 điểm cuối của khách hàng trực tiếp cùng một lúc, thì bạn có thể cần phải ngừng hoạt động để di chuyển...vì sẽ có một số chồng chéo khi bộ nhớ đệm DNS cũ hết hạn.
Ưu điểm của kiểu thiết lập này là tôi có thể chạy trên hầu hết mọi nhà cung cấp VPS có uy tín mà tôi muốn (việc cung cấp tự động của tôi không kén chọn). Tôi không cần phải đầu tư để trở thành một AS và xử lý chi phí bổ sung để quản lý không gian IP của riêng mình (điều này hoàn toàn hợp lý khi làm điều này ở một quy mô nhất định...nhưng tôi không biết tình hình của công ty bạn) .
Tôi có thể thực hiện những việc như cân bằng tải địa lý dựa trên DNS (trả về các IP khác nhau cho cùng một tên tùy thuộc vào khu vực của máy chủ yêu cầu). Điều này cho phép bạn cung cấp cho khách hàng nhiều máy chủ có cùng tên ở các khu vực khác nhau (để họ không phải xử lý độ trễ xuyên Hoa Kỳ hoặc xuyên Đại Tây Dương khi tải ứng dụng). Bạn có thể cung cấp dịch vụ này trên cơ sở từng khách hàng dưới dạng giá trị gia tăng/bán thêm.
Lưu ý cân bằng tải...
Tôi đã đề cập đến cân bằng tải tcp/layer4 nhiều lần mà không giải thích chi tiết. Nói chung, bạn có hai loại cân bằng tải phổ biến. layer4/transport/tcp và layer7/application/http(s).
Bộ cân bằng tải layer7/application/http "nói" http và chấm dứt kết nối ssl trước khi ủy quyền yêu cầu (thường là http không được mã hóa) tới một trong nhiều máy chủ phía sau bộ cân bằng/proxy. Điều này đơn giản nhưng có thể dẫn đến sự cố trong đó các máy chủ phía sau bộ cân bằng tải không biết rằng chúng phải giả vờ như đang nói https khi viết tiêu đề, cookie bảo mật, chuyển hướng, v.v. Điều đó cũng có nghĩa là bộ cân bằng tải của bạn phải làm nhiều việc hơn mỗi yêu cầu (phân tích cú pháp http và xử lý chi phí SSL). Công việc bổ sung này giới hạn khả năng mở rộng của bộ cân bằng tải thường là một nút/máy/vps.
Bộ cân bằng tải layer4/tcp không cần phân tích cú pháp yêu cầu http hoặc có chi phí chấm dứt SSL. Nó không biết gì về http. Yêu cầu được chuyển đến một trong nhiều máy chủ xử lý việc chấm dứt ssl và xử lý yêu cầu http.
Nếu bạn lo lắng về việc sử dụng lại (hoặc thiếu) phiên TLS ảnh hưởng đến hiệu suất, thì thông thường bạn nên sử dụng redis hoặc memcached làm bộ đệm phiên TLS được chia sẻ giữa nhiều máy chủ web để bạn không phải lo lắng về việc bộ cân bằng tải khiến người dùng "dính" vào một hộp cụ thể phía sau bộ cân bằng tải. nginx dường như không hỗ trợ bộ đệm phiên TLS ngoài hộp (bộ đệm chỉ được chia sẻ giữa các nhân viên nginx trên cùng một hộp). haproxy dường như có một cái gì đó nhưng tôi chưa thử và không biết nó sẽ hoạt động như thế nào trong haproxy/level4 trước nhóm nginx nơi xảy ra việc chấm dứt ssl.
Bạn có thể sử dụng nginx hoặc haproxy làm bộ cân bằng tải layer4/tcp, cả hai đều khá dễ thiết lập. Đối với các trường hợp sử dụng nâng cao hơn (và có thể có hiệu suất tốt hơn), bạn cũng có thể xem Máy chủ ảo Linux (LVS).
Một cách khác để phân phối tải là có nhiều bản ghi A hoặc AAAA được trả về cho một tên. Lý tưởng nhất là máy khách DNS chọn ngẫu nhiên từ các địa chỉ được trả về để bạn có được một số phân bổ tải trên nhiều địa chỉ IP. Nếu bạn bắt đầu gặp vấn đề về quy mô với bậc cân bằng tải của mình, thì đây là một cách công nghệ thấp để thêm một số quy mô khác (chỉ cần thêm một bộ cân bằng tải khác vào nhóm máy chủ ứng dụng giống hoặc khác). Tuy nhiên, không có gì buộc khách hàng phải chuyển đổi địa chỉ IP của bạn...vì vậy điều này không cung cấp cho bạn nhiều quyền kiểm soát đối với việc IP nào tải...nhưng có còn hơn không.
