100% thời gian hoạt động cho một ứng dụng web

Chúng tôi đã nhận được một "yêu cầu" thú vị từ một khách hàng ngày hôm nay.

Họ muốn 100% thời gian hoạt động với chuyển đổi dự phòng ngoài trang web trên một ứng dụng web. Từ quan điểm của ứng dụng web của chúng tôi, đây không phải là một vấn đề. Nó được thiết kế để có thể mở rộng ra trên nhiều máy chủ cơ sở dữ liệu, v.v.

Tuy nhiên, từ một vấn đề mạng, tôi dường như không thể tìm ra cách làm cho nó hoạt động.

Tóm lại, ứng dụng sẽ sống trên các máy chủ trong mạng của khách hàng. Nó được truy cập bởi cả người bên trong và bên ngoài. Họ muốn chúng tôi duy trì một bản sao ngoài hệ thống của hệ thống mà trong trường hợp xảy ra sự cố nghiêm trọng tại cơ sở của họ sẽ ngay lập tức nhận và tiếp quản.

Bây giờ chúng tôi biết hoàn toàn không có cách nào để giải quyết nó cho người bên trong (chim bồ câu?), Nhưng họ muốn người dùng bên ngoài thậm chí không nhận thấy.

Thành thật mà nói, tôi không có ý tưởng sương mù nhất về cách điều này có thể có thể. Có vẻ như nếu họ mất kết nối Internet thì chúng ta sẽ phải thực hiện thay đổi DNS để chuyển tiếp lưu lượng truy cập đến các máy bên ngoài ... Tất nhiên, điều này sẽ mất thời gian.

Ý tưởng?

CẬP NHẬT

Tôi đã có một cuộc thảo luận với khách hàng ngày hôm nay và họ đã làm rõ về vấn đề này.

Họ bị mắc kẹt bởi con số 100%, nói rằng ứng dụng nên duy trì hoạt động ngay cả trong trường hợp lũ lụt. Tuy nhiên, yêu cầu đó chỉ có tác dụng nếu chúng tôi lưu trữ nó cho họ. Họ nói rằng họ sẽ xử lý yêu cầu thời gian hoạt động nếu ứng dụng sống hoàn toàn trên máy chủ của họ. Bạn có thể đoán phản ứng của tôi.

Dưới đây là biểu đồ tiện dụng của Wikipedia về việc theo đuổi số phận:

Thật thú vị, chỉ có 3 trong số 20 trang web hàng đầu có thể đạt được 5 số tiền thần thoại hoặc 99,999% thời gian hoạt động trong năm 2007. Họ là Yahoo, AOL và Comcast. Trong 4 tháng đầu năm 2008, một số mạng xã hội phổ biến nhất thậm chí không đến gần với điều đó.

Từ biểu đồ, rõ ràng việc theo đuổi 100% thời gian hoạt động là vô lý như thế nào ...

Yêu cầu họ xác định 100% và cách đo nó trong khoảng thời gian nào. Họ có thể có nghĩa là gần 100% như họ có thể đủ khả năng. Cung cấp cho họ các chi phí.

Để công phu. Tôi đã thảo luận với khách hàng trong nhiều năm qua với các yêu cầu được cho là lố bịch. Trong mọi trường hợp, họ thực sự chỉ sử dụng ngôn ngữ không đủ chính xác.

Thông thường, họ đóng khung mọi thứ theo cách xuất hiện tuyệt đối - như 100% nhưng thực tế khi điều tra sâu hơn, họ đủ hợp lý để thực hiện các phân tích chi phí / lợi ích được yêu cầu khi đưa ra chi phí cho dữ liệu giảm thiểu rủi ro. Hỏi họ làm thế nào họ sẽ đo lường sự sẵn có là một câu hỏi quan trọng. Nếu họ không biết điều này thì bạn đang ở một vị trí phải đề nghị với họ rằng điều này cần được xác định trước.

Tôi sẽ yêu cầu khách hàng xác định điều gì sẽ xảy ra về mặt tác động / chi phí kinh doanh nếu trang web bị sập trong các trường hợp sau:

• Vào giờ bận rộn nhất của họ trong x giờ
• Ít nhất là số giờ bận rộn của họ trong x giờ

Và cũng là cách họ sẽ đo lường điều này.

Bằng cách này, bạn có thể làm việc với họ để xác định mức '100%' phù hợp. Tôi nghi ngờ bằng cách hỏi những loại câu hỏi này, họ sẽ có thể xác định tốt hơn các ưu tiên của các yêu cầu khác của họ. Ví dụ, họ có thể muốn trả một số mức SLA nhất định và thỏa hiệp các chức năng khác để đạt được điều này.

Khách hàng của bạn là điên rồ. 100% thời gian hoạt động là không thể cho dù bạn chi bao nhiêu tiền cho nó. Đơn giản và đơn giản - không thể. Hãy nhìn vào Google, Amazon, v.v. Họ có số tiền gần như vô tận để ném vào cơ sở hạ tầng của họ và họ vẫn có thời gian chết. Bạn cần gửi thông điệp đó cho họ, và nếu họ tiếp tục khăng khăng rằng họ đưa ra những yêu cầu hợp lý. Nếu họ không nhận ra rằng một số lượng thời gian chết là không thể tránh khỏi, thì hãy bỏ qua.

Điều đó nói rằng, bạn dường như có cơ chế mở rộng / phân phối ứng dụng. Phần kết nối mạng sẽ cần liên quan đến các liên kết dự phòng đến các ISP khác nhau, nhận phân bổ ASN và IP, và tìm hiểu sâu về BGP và thiết bị định tuyến thực để không gian địa chỉ IP có thể di chuyển giữa các ISP nếu cần.

Đây rõ ràng là một câu trả lời rất ngắn gọn. Bạn chưa có kinh nghiệm với các ứng dụng yêu cầu mức độ thời gian hoạt động này, vì vậy bạn thực sự cần phải có một chuyên gia tham gia nếu bạn muốn đến bất cứ nơi nào gần với thời gian hoạt động 100% huyền thoại.

Chà, đó chắc chắn là một điều thú vị. Tôi không chắc chắn tôi muốn bản thân có nghĩa vụ hợp đồng 100% thời gian hoạt động, nhưng nếu tôi phải nghĩ rằng nó sẽ trông giống như thế này:

Bắt đầu với IP công cộng trên một bộ cân bằng tải hoàn toàn ra khỏi mạng và xây dựng ít nhất hai trong số chúng để một cái có thể thất bại so với cái kia. Một chương trình như Heatbeart có thể giúp chuyển đổi dự phòng tự động.

Varnish chủ yếu được biết đến như một giải pháp bộ nhớ đệm nhưng nó cũng thực hiện một số cân bằng tải rất tốt. Có lẽ đó sẽ là một lựa chọn tốt để xử lý cân bằng tải. Nó có thể được thiết lập để có 1 đến n phụ trợ được nhóm tùy ý trong các giám đốc sẽ tải số dư ngẫu nhiên hoặc luân chuyển. Varnish có thể được thực hiện đủ thông minh để kiểm tra sức khỏe của mỗi đầu sau và thả các đầu sau không lành mạnh ra khỏi vòng lặp cho đến khi nó trở lại trực tuyến. Các phụ trợ không phải trên cùng một mạng.

Tôi rất thích các IP đàn hồi trong Amazon EC2 những ngày này vì vậy tôi có thể sẽ xây dựng các bộ cân bằng tải của mình trong EC2 ở các khu vực khác nhau hoặc ít nhất là ở các khu vực khả dụng khác nhau trong cùng khu vực. Điều đó sẽ cung cấp cho bạn tùy chọn thủ công (không cho phép) quay vòng cân bằng tải mới nếu bạn phải và di chuyển IP bản ghi A hiện có sang hộp mới.

Varnish không thể chấm dứt SSL, vì vậy, nếu đó là mối quan tâm bạn có thể muốn xem xét một cái gì đó như Nginx thay thế.

Bạn có thể có hầu hết các phụ trợ trong mạng khách hàng của mình và một hoặc nhiều bên ngoài mạng của họ. Tôi tin, nhưng không chắc chắn 100%, rằng bạn có thể ưu tiên các phụ trợ để máy khách của bạn sẽ được ưu tiên cho đến khi tất cả chúng trở nên không lành mạnh.

Đó là nơi tôi sẽ bắt đầu nếu tôi có nhiệm vụ này và chắc chắn sẽ tinh chỉnh nó khi tôi đi cùng.

Tuy nhiên, như @ErikA tuyên bố, đó là Internet và luôn có những phần của mạng nằm ngoài tầm kiểm soát của bạn. Bạn sẽ muốn đảm bảo rằng pháp lý của bạn chỉ ràng buộc bạn với những thứ nằm dưới sự kiểm soát của bạn.

Không có vấn đề - mặc dù từ ngữ hợp đồng sửa đổi một chút:

... Đảm bảo thời gian hoạt động là 100% (làm tròn đến số thập phân bằng 0).

Nếu Facebook và Amazon không thể làm điều đó, thì bạn không thể. Nó đơn giản như vậy.

Để thêm câu trả lời của oconnore từ Hacker News

Tôi không hiểu vấn đề là gì. Khách hàng muốn bạn lên kế hoạch cho thảm họa và họ không định hướng toán học, vì vậy yêu cầu xác suất 100% nghe có vẻ hợp lý. Kỹ sư, như các kỹ sư có xu hướng làm, nhớ ngày đầu tiên của anh ta về prob & stat 101, mà không xem xét rằng khách hàng có thể không. Khi họ nói điều này, họ không nghĩ về mùa đông hạt nhân, họ đang nghĩ về việc Fred vứt cà phê của mình trên máy chủ văn phòng, bị hỏng đĩa hoặc ISP bị hỏng. Hơn nữa, bạn có thể thực hiện điều này. Với các máy chủ tự giám sát, độc lập, độc lập về mặt địa lý, về cơ bản bạn sẽ không có thời gian chết. Với 3 máy chủ hoạt động với độ tin cậy (1) ba 9 độc lập, với các chế độ chuyển đổi dự phòng tốt, thời gian ngừng hoạt động dự kiến ​​của bạn là dưới một giây mỗi năm (2). Ngay cả khi điều này xảy ra cùng một lúc, bạn vẫn ở trong một SLA hợp lý cho các kết nối web và do đó, thời gian chết thực tế không tồn tại. Khách hàng vẫn phải đối phó với các kịch bản ngày tận thế, nhưng Godzilla loại trừ, anh ta sẽ có một dịch vụ "luôn luôn" lên.

(1) Một máy chủ ở LA độc lập hợp lý với máy chủ ở Boston, nhưng vâng, tôi hiểu rằng có một số giao lộ liên quan đến chiến tranh hạt nhân, tin tặc Trung Quốc làm sập lưới điện, v.v. Tôi không nghĩ khách hàng của bạn sẽ buồn vì điều này.

(2) Chuyển đổi dự phòng DNS có thể thêm một vài giây. Bạn vẫn đang ở trong một kịch bản mà khách hàng phải thử lại yêu cầu mỗi năm một lần, một lần nữa, trong SLA hợp lý, và thường không được coi là cùng một lúc là "thời gian chết". Với một ứng dụng tự động định tuyến lại đến một nút có sẵn khi bị lỗi, điều này có thể không được chú ý.

Bạn đang được yêu cầu một cái gì đó không thể.

Xem lại các câu trả lời khác ở đây, ngồi xuống với khách hàng của bạn và giải thích TẠI SAO điều đó là không thể, và đánh giá phản ứng của họ.

Nếu họ vẫn khăng khăng 100% thời gian hoạt động, hãy lịch sự thông báo cho họ rằng không thể thực hiện và từ chối hợp đồng. Bạn sẽ không bao giờ đáp ứng nhu cầu của họ và nếu hợp đồng không hoàn toàn bị hút, bạn sẽ bị sai lệch với các hình phạt.

Giá phù hợp, và sau đó quy định trong hợp đồng rằng bất kỳ thời gian chết nào qua SLA sẽ được hoàn trả theo tỷ lệ họ đang trả.

ISP tại công việc cuối cùng của tôi đã làm điều đó. Chúng tôi đã lựa chọn một đường DSL "thông thường" với 99,9% thời gian hoạt động với giá 40 đô la / tháng, hoặc bộ ba ngoại quan của T1 với 99,99% thời gian hoạt động với giá 1100 đô la / tháng. Có những lần mất điện thường xuyên hơn 10 giờ mỗi tháng, khiến thời gian hoạt động của họ thấp hơn mức DSL $ 40 / tháng, nhưng chúng tôi chỉ được hoàn lại khoảng 15 đô la hoặc hơn, vì đó là mức giá mỗi giờ * giờ kết thúc. Họ đã thực hiện như kẻ cướp từ thỏa thuận.

Nếu bạn lập hóa đơn 450.000 đô la một tháng cho 100% thời gian hoạt động và bạn chỉ đạt 99,999%, bạn sẽ cần hoàn lại cho họ $ 324. Tôi sẵn sàng đặt cược chi phí cơ sở hạ tầng để đạt 99,999% trong khu vực 45.000 đô la một tháng với giả định colos được phân phối đầy đủ, nhiều liên kết cấp 1, phần cứng ưa thích, v.v.

Nếu các chuyên gia đặt câu hỏi nếu 99.999 phần trăm khả dụng [là] có khả năng thực tế hay khả thi về tài chính hay không , thì khả năng sẵn sàng 99.9999% thậm chí còn ít khả thi hoặc thực tế hơn. Hãy để một mình 100%.

Bạn sẽ không đáp ứng mục tiêu khả dụng 100% trong một khoảng thời gian dài. Bạn có thể thoát khỏi nó trong một tuần hoặc một năm, nhưng sau đó điều gì đó sẽ xảy ra và bạn sẽ phải chịu trách nhiệm. Sự ra đi có thể từ danh tiếng bị tổn hại (bạn đã hứa, bạn đã không giao hàng) đến phá sản từ tiền phạt theo hợp đồng.

Có hai loại người yêu cầu 100% thời gian hoạt động:

1. Những người hoàn toàn không có kiến ​​thức về máy tính, hệ thống máy tính hoặc Internet. *
2. Những người cố tình tự lừa mình, để kiểm tra khả năng của bạn để nói Không (Google "Thử nghiệm nước cam") hoặc cố gắng đạt được một loại đòn bẩy SLA hợp đồng nào đó để thoát khỏi việc trả tiền cho bạn sau này.

Lời khuyên của tôi, đã chịu đựng cả hai loại khách hàng này trong nhiều trường hợp, là không lấy khách hàng này. Hãy để họ lái xe người khác điên.

* Người này cũng có thể không bối rối khi tìm hiểu về du lịch nhanh hơn ánh sáng, Chuyển động vĩnh viễn, Fusion lạnh, v.v.

Tôi sẽ liên lạc với khách hàng để thiết lập với họ chính xác thời gian hoạt động chính xác 100%. Có thể họ không thực sự thấy sự khác biệt giữa 99% thời gian hoạt động và 100% thời gian hoạt động. Đối với hầu hết mọi người (ví dụ: không phải quản trị viên máy chủ) hai số đó là như nhau.

100% thời gian hoạt động?

Đây là những gì bạn cần:

Nhiều máy chủ DNS (& dự phòng), trỏ đến nhiều trang web trên toàn thế giới, với SLA phù hợp với mỗi ISP.

Đảm bảo rằng các máy chủ DNS được thiết lập đúng, với hiệu quả được nhận dạng bằng TTL.

Điều này thật dễ dàng. Amazon EC2 SLA nêu rõ:

Tỷ lệ phần trăm thời gian hoạt động hàng năm của trực tiếp được tính bằng cách trừ 100% phần trăm thời gian 5 phút trong Năm dịch vụ mà Amazon EC2 ở trạng thái Vùng không có sẵn.

http://aws.amazon.com/ec2-sla/

Chỉ cần xác định 'thời gian hoạt động' là tương đối với toàn bộ gói dịch vụ mà bạn thực sự có thể duy trì hoạt động 100% thời gian và bạn sẽ không gặp vấn đề gì.

Ngoài ra, đáng để chỉ ra rằng toàn bộ quan điểm của SLA là xác định nghĩa vụ của bạn là gì và điều gì xảy ra nếu bạn không thể đáp ứng chúng. Sẽ không có vấn đề gì nếu khách hàng yêu cầu 3 số tiền phạt hoặc 5 số tiền phạt hoặc một triệu số tiền phạt - câu hỏi là họ nhận được gì khi / nếu bạn không thể giao hàng. Câu trả lời rõ ràng là cung cấp một chi tiết đơn hàng cho thời gian hoạt động 100% với mức giá gấp 5 lần bạn muốn tính phí và sau đó họ sẽ được hoàn lại gấp 4 lần nếu bạn bỏ lỡ mục tiêu đó. Bạn có thể ghi bàn!

Thay đổi DNS chỉ mất thời gian nếu chúng được cấu hình để mất thời gian. Bạn có thể đặt TTL trên một bản ghi thành một giây - vấn đề duy nhất của bạn là đảm bảo rằng bạn cung cấp phản hồi kịp thời cho các truy vấn DNS và máy chủ DNS có thể đối phó với mức truy vấn đó.

Đây chính xác là cách GTM hoạt động trong F5 Big IP - DNS TTL theo mặc định được đặt thành 30 giây và nếu một thành viên của cụm cần tiếp quản, DNS sẽ được cập nhật và IP mới được đưa lên gần như ngay lập tức. Tối đa 30 giây ngừng hoạt động, nhưng đó là trường hợp cạnh, trung bình sẽ là 15 giây.

Bạn biết điều này là không thể.

Không còn nghi ngờ gì nữa, khách hàng tập trung vào việc xem "100%", vì vậy điều tốt nhất bạn có thể làm là hứa 100%, ngoại trừ [tất cả các nguyên nhân hợp lý không phải là lỗi của bạn].

Mặc dù tôi nghi ngờ 100% là có thể, bạn có thể muốn coi Azure (hoặc một cái gì đó có SLA tương tự) là một khả năng. Điều gì xảy ra:

Máy chủ của bạn là máy ảo. Nếu có sự cố phần cứng trên một máy chủ, máy ảo của bạn sẽ được chuyển sang một máy mới. Bộ cân bằng tải đảm nhiệm việc chuyển hướng để khách hàng không thấy bất kỳ thời gian chết nào (mặc dù tôi không chắc trạng thái phiên của bạn sẽ bị ảnh hưởng như thế nào).

Điều đó nói rằng, ngay cả với thất bại này, sự khác biệt giữa 99.999 và 100 biên giới về sự điên rồ.

Bạn sẽ phải kiểm soát hoàn toàn các yếu tố sau.
- Yếu tố con người, cả bên trong và bên ngoài, cả ác ý và bất lực. Một ví dụ về điều này là ai đó đang đẩy một cái gì đó vào mã sản xuất đưa xuống một máy chủ. Tệ hơn nữa, còn việc phá hoại thì sao?
- Vấn đề kinh doanh. Điều gì sẽ xảy ra nếu nhà cung cấp của bạn hết thời gian hoặc quên thanh toán hóa đơn điện của họ, hoặc đơn giản là quyết định ngừng hỗ trợ cơ sở hạ tầng của bạn mà không có cảnh báo đầy đủ?
- Thiên nhiên. Điều gì xảy ra nếu các cơn lốc xoáy không liên quan đồng thời tấn công đủ các trung tâm dữ liệu để áp đảo khả năng sao lưu?
- Một môi trường hoàn toàn không có lỗi. Bạn có chắc chắn không có trường hợp cạnh với một số bên thứ ba hoặc kiểm soát hệ thống cốt lõi không tự thể hiện nhưng vẫn có thể làm như vậy trong tương lai?
- Ngay cả khi bạn có toàn quyền kiểm soát các yếu tố trên, bạn có chắc phần mềm / người giám sát việc này sẽ không cung cấp cho bạn âm tính giả khi kiểm tra xem hệ thống của bạn có hoạt động không?

Thành thật 100% là hoàn toàn điên rồ mà không có ít nhất một người do dự về các cuộc tấn công hack. Đặt cược tốt nhất của bạn là làm những gì Google và Amazon làm trong đó bạn có một giải pháp lưu trữ được phân phối theo địa lý nơi bạn có trang web và DB được nhân rộng trên nhiều máy chủ ở nhiều vị trí địa lý. Điều này sẽ đảm bảo nó trong bất cứ điều gì ngoại trừ một thảm họa lớn như đường trục internet bị cắt đến một khu vực (xảy ra theo thời gian) hoặc một cái gì đó gần như tận thế.

Tôi sẽ đưa ra một điều khoản cho những trường hợp như vậy (DDOS, cắt xương sống internet, tấn công khủng bố tận thế hoặc một cuộc chiến lớn, v.v.).

Khác với điều đó nhìn vào các dịch vụ đám mây của Amazon S3 hoặc Rackspace. Về cơ bản, thiết lập đám mây sẽ không chỉ cung cấp dự phòng ở từng vị trí mà còn cả khả năng mở rộng và phân phối lưu lượng địa lý cùng với khả năng chuyển hướng xung quanh các khu vực địa lý bị lỗi. Mặc dù hiểu biết của tôi là phân phối địa lý tốn nhiều tiền hơn.

Tôi chỉ muốn thêm một giọng nói khác với "nó có thể bên (trên lý thuyết) được thực hiện".

Tôi sẽ không tham gia một hợp đồng có quy định này cho dù họ trả cho tôi bao nhiêu, nhưng như một vấn đề nghiên cứu, nó có một số giải pháp khá thú vị. Tôi không đủ quen thuộc với mạng để phác thảo các bước, nhưng tôi tưởng tượng sự kết hợp của các cấu hình liên quan đến mạng + lỗi dây điện / phần cứng + lỗi phần mềm, có thể, trong một số cấu hình hoặc công việc khác thực sự sẽ tắt nó.

Hầu như luôn luôn có một điểm thất bại duy nhất ở bất kỳ cấu hình nào, nhưng nếu bạn làm việc đủ chăm chỉ, bạn có thể đẩy điểm thất bại đó thành một thứ có thể được sửa chữa "trực tiếp" (tức là root dns bị hỏng, nhưng các giá trị vẫn được lưu trữ mọi nơi khác để bạn có thời gian sửa nó).

Một lần nữa, không nói điều đó là khả thi .. Tôi chỉ không thích làm thế nào mà không một câu trả lời nào đề cập đến thực tế rằng đó không phải là "lối thoát" - đó không phải là điều họ thực sự muốn nếu họ nghĩ đến.

Nghĩ lại phương pháp đo lường tính khả dụng của bạn sau đó làm việc với khách hàng của bạn để đặt các mục tiêu có ý nghĩa .

Nếu bạn đang chạy một trang web lớn, thời gian hoạt động không hữu ích chút nào. Nếu bạn bỏ truy vấn trong 10 phút khi khách hàng của bạn cần chúng nhất (cao điểm lưu lượng truy cập), điều đó có thể gây hại cho doanh nghiệp hơn là mất điện kéo dài một giờ vào lúc 3 giờ sáng Chủ nhật.

Đôi khi các công ty web lớn đo lường tính khả dụng hoặc độ tin cậy bằng cách sử dụng các số liệu sau:

1. phần trăm truy vấn được trả lời thành công mà không có lỗi phía máy chủ (HTTP 500s).
2. tỷ lệ truy vấn được trả lời dưới độ trễ mục tiêu nhất định .
3. truy vấn bị bỏ sẽ được tính theo số liệu thống kê của bạn (xem bên dưới).

Tình trạng sẵn có nên không được đo bằng thiết bị thăm dò mẫu, đó là những gì một thực thể bên ngoài như Pingdom và pingability có thể báo cáo. Đừng chỉ dựa vào điều đó. Nếu bạn muốn làm đúng, mỗi truy vấn sẽ được tính . Đo lường sự sẵn có của bạn bằng cách nhìn vào thành công thực tế, nhận thức của bạn.

Cách hiệu quả nhất là thu thập nhật ký hoặc số liệu thống kê từ bộ cân bằng tải của bạn và tính toán tính khả dụng dựa trên các số liệu ở trên.

Tỷ lệ truy vấn bị bỏ cũng sẽ được tính vào số liệu thống kê của bạn. Nó có thể được tính trong cùng một nhóm như lỗi phía máy chủ. Nếu có vấn đề với mạng hoặc với cơ sở hạ tầng khác như DNS hoặc bộ cân bằng tải, bạn có thể sử dụng toán đơn giản để ước tính số lượng truy vấn bạn đã mất . Nếu bạn mong đợi các truy vấn X cho ngày đó trong tuần nhưng bạn đã nhận được X-1000, có lẽ bạn đã bỏ 1000 truy vấn. Vẽ lưu lượng truy cập của bạn vào các biểu đồ truy vấn mỗi phút (hoặc giây). Nếu khoảng trống xuất hiện, bạn bỏ các truy vấn. Sử dụng hình học cơ bản để đo diện tích của những khoảng trống đó, cung cấp cho bạn tổng số truy vấn bị bỏ.

Thảo luận về phương pháp này với khách hàng của bạn và giải thích lợi ích của nó. Đặt đường cơ sở bằng cách đo tính khả dụng hiện tại của chúng. Họ sẽ trở nên rõ ràng rằng 100% là mục tiêu không thể.

Sau đó, bạn có thể ký hợp đồng dựa trên những cải tiến trên đường cơ sở. Giả sử, nếu họ hiện đang trải nghiệm 95% khả dụng, bạn có thể hứa sẽ cải thiện tình hình gấp mười lần bằng cách đạt tới 98,5%.

Lưu ý: có những nhược điểm đối với cách đo lường tính khả dụng này. Đầu tiên, tự mình thu thập nhật ký, xử lý và tạo báo cáo có thể không tầm thường, trừ khi bạn sử dụng các công cụ hiện có để thực hiện. Thứ hai, lỗi ứng dụng có thể làm tổn thương tính khả dụng của bạn. Nếu ứng dụng có chất lượng thấp, nó sẽ phục vụ nhiều lỗi hơn. Giải pháp cho vấn đề này là chỉ xem xét số 500 được tạo bởi bộ cân bằng tải thay vì những thứ đến từ ứng dụng.

Mọi thứ có thể hơi phức tạp theo cách này, nhưng đó là một bước ngoài việc đo thời gian hoạt động của máy chủ .

Trong khi một số người lưu ý ở đây, 100% là điên rồ hoặc không thể , bằng cách nào đó họ đã bỏ lỡ điểm thực sự. Họ lập luận rằng lý do cho điều này là thực tế là ngay cả những công ty / dịch vụ tốt nhất cũng không thể đạt được nó.

Chà, nó đơn giản hơn thế nhiều. Về mặt toán học là không thể .

Mọi thứ đều có xác suất. Có thể có một trận động đất đồng thời tại tất cả các địa điểm nơi bạn lưu trữ máy chủ của mình, phá hủy tất cả chúng. Có thể đó là một xác suất nhỏ đến mức nực cười, nhưng không phải là 0. Tất cả các nhà cung cấp internet của bạn có thể phải đối mặt với một cuộc tấn công khủng bố / mạng đồng thời. Một lần nữa, không có nhiều khả năng, nhưng cũng không phải là không. Bất cứ điều gì bạn cung cấp, bạn đều có thể có được một kịch bản xác suất khác không, điều này sẽ làm giảm toàn bộ dịch vụ. Bởi vì điều này, thời gian hoạt động của bạn không thể là 100%.

Đi lấy một cuốn sách về kiểm soát chất lượng sản xuất bằng cách sử dụng lấy mẫu thống kê. Một cuộc thảo luận chung trong cuốn sách này, các khái niệm mà bất kỳ nhà quản lý nào sẽ được tiếp xúc trong một khóa học thống kê chung ở trường đại học, đã đưa ra các chi phí để đi từ 1 bài trừ trong một nghìn, đến 1 phần nghìn đến 1 trong một triệu 1 trong một tỷ tăng theo cấp số nhân. Về cơ bản, khả năng đạt 100% thời gian hoạt động sẽ tiêu tốn một lượng tiền gần như không giới hạn, giống như lượng nhiên liệu cần thiết để đẩy một vật thể tới tốc độ ánh sáng.

Từ góc độ kỹ thuật hiệu suất, tôi sẽ từ chối yêu cầu là không thể kiểm chứng và không hợp lý, rằng biểu hiện này là một mong muốn nhiều hơn là một yêu cầu thực sự. Với các phụ thuộc ứng dụng tồn tại bên ngoài bất kỳ ứng dụng nào để kết nối mạng, phân giải tên, định tuyến, lỗi được hỗ trợ từ các thành phần kiến ​​trúc cơ bản hoặc các công cụ phát triển, nó trở thành một điều không thể thực tế khi có bất kỳ ai đảm bảo 100% thời gian hoạt động.

Tôi không nghĩ rằng khách hàng thực sự yêu cầu 100% thời gian hoạt động, hoặc thậm chí 99,999% thời gian hoạt động. Nếu bạn nhìn vào những gì họ đang mô tả, họ sẽ nói về việc chọn nơi họ rời đi nếu một thiên thạch lấy ra trung tâm dữ liệu tại chỗ của họ.

Nếu yêu cầu là người bên ngoài thậm chí không nhận thấy, làm thế nào quyết liệt phải được? Việc thực hiện yêu cầu Ajax thử lại và hiển thị một công cụ quay vòng trong 30 giây cho người dùng cuối có được chấp nhận không?

Đó là những điều khách hàng quan tâm. Nếu khách hàng thực sự nghĩ về SLA chính xác, thì họ sẽ biết đủ để thể hiện nó là 99,99 hoặc 99,999.

2 xu của tôi. Tôi chịu trách nhiệm cho một trang web rất phổ biến cho một công ty fortune-5, người sẽ đưa ra quảng cáo cho siêu bát. Tôi đã phải đối phó với lưu lượng truy cập lớn và cách tôi giải quyết là sử dụng một dịch vụ như Akamai. Tôi không làm việc cho Akamai nhưng tôi thấy dịch vụ của họ cực kỳ tốt. Họ có hệ thống DNS thông minh hơn, thông minh hơn với một nút / máy chủ cụ thể đang bị tải nặng hoặc bị ngừng hoạt động và có thể định tuyến lưu lượng phù hợp.

Điều thú vị về dịch vụ của họ là tôi thực sự không phải làm gì quá phức tạp để sao chép nội dung trên các máy chủ trong trung tâm dữ liệu của riêng tôi sang trung tâm dữ liệu của họ. Ngoài ra, tôi biết khi làm việc với họ, họ đã sử dụng rất nhiều máy chủ HTTP Apache.

Mặc dù không phải 100% thời gian hoạt động, bạn có thể xem xét các tùy chọn như vậy để phân tán nội dung trên toàn thế giới. Theo tôi hiểu, Akamai cũng có khả năng bản địa hóa ý nghĩa giao thông nếu tôi ở Michigan, tôi nhận được nội dung từ máy chủ Michigan / Chicago và nếu tôi ở California, tôi đã nhận được nội dung từ máy chủ có trụ sở tại California.

Thay vì chuyển đổi dự phòng ngoài trang web, chỉ cần chạy ứng dụng từ hai vị trí đồng thời, bên trong và bên ngoài. Và đồng bộ hóa hai cơ sở dữ liệu ... Sau đó, nếu nội bộ đi xuống, những người bên trong vẫn có thể làm việc và những người bên ngoài vẫn có thể sử dụng ứng dụng. Khi nội bộ trở lại trực tuyến, đồng bộ hóa các thay đổi. Bạn có thể có hai mục nhập DNS cho một tên miền hoặc thậm chí bộ định tuyến mạng với vòng tròn.

Đối với các trang web được lưu trữ bên ngoài, thời gian hoạt động gần nhất 100% sẽ lưu trữ trang web của bạn trên Máy ứng dụng của Google và sử dụng kho dữ liệu sao chép cao (HRD) , tự động sao chép dữ liệu của bạn qua ít nhất ba trung tâm dữ liệu trong thời gian thực. Tương tự, các máy chủ ngoại vi của Máy ứng dụng được tự động thu nhỏ / sao chép cho bạn.

Tuy nhiên, ngay cả với tất cả các tài nguyên của Google và nền tảng tinh vi nhất trên thế giới, bảo đảm thời gian hoạt động của SLA của App Engine chỉ là "99,95% thời gian trong bất kỳ tháng nào theo lịch".

Đơn giản và trực tiếp: Anycast

http://en.wikipedia.org/wiki/Anycast

Đây là những gì mà cloudflare, google và bất kỳ công ty lớn nào khác sử dụng để thực hiện dự phòng, độ trễ thấp, thất bại / cân bằng xuyên lục địa.

Nhưng cũng nên nhớ rằng không thể có 100% thời gian hoạt động và chi phí phải trả từ 99.999% đến 99.9999% là lớn hơn.