Câu hỏi thiết lập tính sẵn sàng cao toàn cầu

Tôi sở hữu và vận hành visualwebsiteoptimizer.com /. Ứng dụng cung cấp một đoạn mã mà khách hàng của tôi chèn vào trang web của họ để theo dõi các số liệu nhất định. Vì đoạn mã là JavaScript bên ngoài (ở đầu mã trang web), trước khi hiển thị trang web của khách hàng, trình duyệt của khách truy cập liên hệ với máy chủ ứng dụng của chúng tôi. Trong trường hợp máy chủ ứng dụng của chúng tôi gặp sự cố, trình duyệt sẽ tiếp tục cố gắng thiết lập kết nối trước khi hết thời gian (thường là 60 giây). Như bạn có thể tưởng tượng, chúng tôi không thể để máy chủ ứng dụng của chúng tôi ngừng hoạt động trong bất kỳ tình huống nào vì nó sẽ ảnh hưởng tiêu cực đến trải nghiệm của không chỉ khách truy cập trang web của chúng tôi mà cả khách truy cập trang web của khách hàng của chúng tôi!

Chúng tôi hiện đang sử dụng cơ chế chuyển đổi dự phòng DNS với một máy chủ dự phòng nằm trong một trung tâm dữ liệu khác nhau (thực sự là lục địa khác nhau). Đó là, chúng tôi giám sát máy chủ ứng dụng của chúng tôi từ 3 vị trí riêng biệt và ngay khi phát hiện thấy nó bị hỏng, chúng tôi thay đổi một bản ghi để trỏ đến IP máy chủ dự phòng. Điều này hoạt động tốt đối với hầu hết các trình duyệt (vì TTL của chúng tôi là 2 phút) nhưng IE lưu trữ DNS trong 30 phút có thể là một kẻ giết người thỏa thuận. Xem bài đăng gần đây của chúng tôi visualwebsiteoptimizer.com/split-testing-blog/maximum-theorories-dftimeime-for-a-website-30-minutes/

Vì vậy, loại thiết lập nào chúng ta có thể sử dụng để đảm bảo chuyển đổi dự phòng gần như ngay lập tức trong trường hợp trung tâm dữ liệu ứng dụng bị mất điện lớn? Tôi đọc ở đây www.tenereillo.com/GSLBPageOfShame.htm rằng có nhiều bản ghi A là một giải pháp nhưng chúng tôi không thể đủ khả năng đồng bộ hóa phiên (chưa). Một chiến lược khác mà chúng tôi đang khám phá là có hai bản ghi A, một chỉ đến máy chủ ứng dụng và thứ hai là proxy ngược (nằm trong một trung tâm dữ liệu khác) sẽ phân giải đến máy chủ ứng dụng chính nếu nó lên và đến máy chủ dự phòng nếu nó hoạt động. Bạn có nghĩ rằng chiến lược này là hợp lý?

Chỉ cần chắc chắn về các ưu tiên của chúng tôi, chúng tôi có thể đủ khả năng để giữ trang web hoặc ứng dụng của riêng mình nhưng chúng tôi không thể để trang web của khách hàng chậm lại do thời gian ngừng hoạt động. Vì vậy, trong trường hợp máy chủ ứng dụng của chúng tôi ngừng hoạt động, chúng tôi không có ý định phản hồi với phản hồi ứng dụng mặc định. Ngay cả một phản hồi trống cũng đủ, chúng tôi chỉ cần trình duyệt đó hoàn thành kết nối HTTP đó (và không có gì khác).

Tham khảo: Tôi đã đọc chủ đề này rất hữu ích serverfault.com/questions/69870/mult Môn-data-centers-and-http-Traffic-dns -round-rrobin-is-the-on-way-to -assure

Tình hình của bạn khá giống với chúng ta. Chúng tôi muốn chia trung tâm dữ liệu và chuyển đổi dự phòng loại lớp mạng.

Nếu bạn có ngân sách để thực hiện, thì điều bạn muốn, là hai trung tâm dữ liệu, nhiều lần truyền IP cho mỗi, một cặp bộ định tuyến biên thực hiện các phiên BGP cho nhà cung cấp dịch vụ vận chuyển của bạn, quảng cáo địa chỉ IP của bạn lên internet toàn cầu.

Đây là cách duy nhất để thực hiện chuyển đổi dự phòng thực sự. Khi các bộ định tuyến nhận thấy rằng tuyến đến máy chủ của bạn không còn hợp lệ (mà bạn có thể thực hiện theo một số cách), sau đó họ dừng quảng cáo tuyến đó và lưu lượng truy cập đến trang web khác.

Vấn đề là, đối với một cặp bộ định tuyến biên, ban đầu bạn đang xem chi phí khá cao để thiết lập thiết bị này.
Sau đó, bạn cần thiết lập mạng phía sau tất cả những điều này và bạn có thể muốn xem xét một số loại kết nối Layer2 giữa các trang web của mình dưới dạng liên kết điểm-điểm để bạn có khả năng định tuyến lưu lượng truy cập đến một trung tâm dữ liệu, trực tiếp đến cái khác trong trường hợp thất bại một phần của trang web chính của bạn.

BGP Multihomed / Đa vị trí thực hành tốt nhất và Cách tốt nhất để cải thiện khả năng phục hồi? là những câu hỏi mà tôi đã hỏi về các vấn đề tương tự.

Trang xấu hổ của GSLB nêu lên một số điểm quan trọng, đó là lý do tại sao, cá nhân tôi không bao giờ sẵn lòng chọn một GSLB để thực hiện công việc định tuyến BGP.

Bạn cũng nên xem xét các điểm thất bại khác trong mạng của bạn. Đảm bảo rằng tất cả các máy chủ có 2 NIC (được kết nối với 2 công tắc riêng biệt), 2 PSU và dịch vụ của bạn bao gồm nhiều máy chủ phụ trợ, dưới dạng cặp dự phòng hoặc cụm cân bằng tải.

Về cơ bản, DNS "cân bằng tải" thông qua nhiều bản ghi A chỉ là "chia sẻ tải" vì máy chủ DNS không có khái niệm về mức độ tải trên mỗi máy chủ. Đây là giá rẻ (miễn phí).

Dịch vụ GSLB có một số khái niệm về mức độ tải của máy chủ và tính khả dụng của chúng và cung cấp khả năng chống lại sự thất bại lớn hơn, nhưng vẫn bị ảnh hưởng bởi các vấn đề liên quan đến bộ nhớ đệm dns và chốt. Điều này là ít rẻ hơn, nhưng tốt hơn một chút.

Mạng định tuyến BGP, được hỗ trợ bởi cơ sở hạ tầng vững chắc, là IMHO, cách duy nhất để thực sự đảm bảo thời gian hoạt động tốt. Bạn có thể tiết kiệm một số tiền bằng cách sử dụng các máy chủ định tuyến thay vì bộ định tuyến Cisco / Juniper / etc, nhưng vào cuối ngày, bạn cần phải quản lý các máy chủ này thật cẩn thận. Đây không phải là một lựa chọn rẻ tiền, hoặc một cái gì đó được thực hiện nhẹ nhàng, nhưng nó là một giải pháp rất bổ ích và đưa bạn vào internet như một nhà cung cấp, thay vì chỉ là một người tiêu dùng.

OK, điều này đã được hỏi cách đây một thời gian, nhưng lần đầu tiên tôi nhìn thấy nó bây giờ.

đoạn mã là JavaScript bên ngoài (ở đầu mã trang web), trước khi hiển thị trang web của khách hàng, trình duyệt của khách truy cập liên hệ với máy chủ ứng dụng của chúng tôi.

Bạn nên:

1. Đặt tệp Javascript của bạn trên Mạng phân phối nội dung tốt, chuyên nghiệp, nghĩa là mua phân phối HTTP (S) có tính sẵn sàng cao từ một người đã có chuyên môn đó.
2. Lập trình Javascript của bạn để có trạng thái dự phòng tốt, tức là nếu máy chủ ứng dụng của bạn không phản hồi nhanh thì người dùng cuối sẽ thấy một trang bình thường, không được sửa đổi.

Làm bất cứ điều gì khác là vô trách nhiệm, thực sự. Tôi giả sử bạn đã có điều này tại chỗ.

Bạn không nên căn cứ dịch vụ của mình vào các thủ thuật định tuyến BGP trừ khi bạn có hoặc có được bí quyết để làm điều đó. Các kịch bản định tuyến BGP phức tạp được quyết định là không tầm thường để thực hiện; đừng tự làm điều này nếu bạn không có kiến ​​thức cụ thể về tên miền.

Câu hỏi của bạn là một chút bối rối. Phân tích về cách tạo một dịch vụ khả dụng cao bắt đầu bằng dữ liệu ứng dụng , vì đó là "trạng thái" của bạn. Các bộ phận không trạng thái là dễ dàng để làm cho có sẵn cao, các bộ phận nhà nước đầy đủ là không. Vì vậy, thay vì tập trung vào máy chủ và DNS của bạn, hãy nhìn vào nơi ứng dụng của bạn duy trì trạng thái . Bắt đầu bằng cách tối ưu hóa ở đó và có thể yêu cầu lời khuyên về thuật toán trên Stack Overflow. Bạn có thể thực hiện khái niệm giao dịch và thử lại máy chủ thông minh trong tệp Javascript fx của mình không?

Trên thực tế, những gì bạn muốn có thể được nâng cấp để giúp các hoạt động thử nghiệm phân tách của bạn cũng như nếu bạn kết hợp chuyển đổi địa lý và chuyển đổi dự phòng.

Gửi nhóm A đến ip 1 và nhóm B đến ip 2, ngay cả khi chúng ở trên cùng một máy chủ sẽ cho phép bạn tách các nhóm thử nghiệm của mình. Nhóm A và nhóm B đến từ các khu vực địa lý khác nhau. Để công bằng, ngày / tuần / tháng tiếp theo, bạn lật các nhóm để đảm bảo rằng bạn cho phép sự khác biệt về địa lý. Chỉ cần nghiêm ngặt trong phương pháp của bạn.

Dịch vụ geodns / failover dns tại http://edgedirector.com có thể làm điều này

tiết lộ: tôi được liên kết với các liên kết ở trên, tình cờ tìm thấy một bài viết về việc áp dụng các thủ thuật dns ngu ngốc để thử nghiệm phân tách.