Chúng tôi hiện có một ứng dụng n-tier cổ điển: DB / dịch vụ web / front-end. Nó có các thành phần khác, nhưng đó là cách bố trí cơ bản.

Chúng tôi muốn cải thiện tính khả dụng của ứng dụng vì 3 lý do chính:

1. Máy chủ của chúng tôi đôi khi gặp sự cố ngừng hoạt động (như tất cả đều như vậy) và chúng tôi muốn giảm thiểu tác động đến khách hàng của mình, vì vậy, họ sẽ bật trung tâm dữ liệu B nếu trung tâm dữ liệu A không hoạt động.
2. Khi chúng tôi nâng cấp phiên bản, chúng tôi sẽ tắt trang web để bảo trì và thường mất vài giờ (tập lệnh di chuyển, v.v.). Chúng tôi muốn người dùng có một quá trình chuyển đổi liền mạch hơn, với thời gian chết tối thiểu nhất có thể (họ sử dụng máy chủ B trong khi máy chủ A đang được nâng cấp).
3. Tùy chọn, khách hàng của chúng tôi ở khắp nơi trên thế giới và chúng tôi muốn họ có trải nghiệm tốt nhất có thể mặc dù các kết nối có thể nhảm nhí của họ (bất kỳ ai làm việc với các nhà phát triển Ấn Độ nên biết ý tôi là gì). Lý tưởng nhất là chúng tôi muốn có thể cắm một máy chủ trong văn phòng của họ (hoặc sử dụng một trung tâm dữ liệu gần thành phố của họ) và nó sẽ tích hợp hoàn toàn vào kiến ​​trúc của chúng tôi.

Chúng tôi không cần từ xa 99% khả dụng, thậm chí 95%. Đây là một ứng dụng quản lý tài liệu. Không ai quan tâm. Nhưng vì việc di chuyển có thể mất một thời gian và có khách hàng trên khắp thế giới, đôi khi chúng tôi ngăn khách hàng làm việc trong phần lớn thời gian trong ngày của họ.

Đối với phần SQL, mặc dù không có các DBA "phù hợp", chúng tôi biết về các khả năng của SQL : sao chép, phản chiếu, v.v ... Về phía DB, việc tìm tài nguyên cho việc này khá dễ dàng. Mọi thứ khác khó hơn: lưu trữ phiên, mã, v.v ... Nếu máy chủ dịch vụ web của tôi bị hỏng, làm thế nào để giao diện người dùng của tôi biết nó phải chuyển đổi? Làm thế nào các phiên của tôi vẫn tồn tại trên các máy chủ?

Thật không may, không ai trong chúng tôi có kinh nghiệm trong lĩnh vực này và thậm chí chúng tôi không biết bắt đầu tìm kiếm ở đâu. Có thực hành tốt nhất cho điều này? Thiết kế mẫu nào? Thư viện (cần miễn phí vì chúng tôi không có tiền)?

Chúng tôi đang sử dụng ASP.Net và SQL Server, với dịch vụ web WCF ở giữa. Chúng tôi có một loạt các dịch vụ Windows nằm xung quanh, nhưng chúng không phải là nhiệm vụ quan trọng và tôi cho rằng các phương pháp để đối phó với trang web sẽ được áp dụng cho các dịch vụ.

Tôi hiểu rằng hầu hết các nền tảng đám mây đều cung cấp một hệ thống tích hợp cho việc này, nhưng lưu trữ đám mây là điều không nên vì sysadmin của chúng tôi, những người muốn tự mình quản lý mọi thứ và không dựa vào ai.

Bạn cần làm rõ loại khả năng sẵn sàng cao mà bạn đang tìm kiếm. Có những ứng dụng khả dụng cao mà tôi chạy cần tới 95%. Có những người khác cần phải chạy ở mức 99%. Tôi có thể nghĩ về các kịch bản sống hay chết đòi hỏi 100% thời gian hoạt động. Chỉ có ba người có cách tiếp cận và chi phí rất khác nhau.

Chỉ cần đoán dựa trên nhu cầu của bạn và SLA 95-99% thời gian hoạt động:

• Di chuyển cơ sở dữ liệu sẽ có thể xảy ra trong thời gian thực cho hầu hết các thay đổi. Thực hành thiết kế cơ sở dữ liệu tiến hóa . Đối với những thay đổi đòi hỏi hành vi xâm lấn nhiều hơn, bạn có một vài lựa chọn. Một là lấy thời gian chết. Nếu có thể, chạy dịch vụ của bạn ở chế độ chỉ đọc có thể hoạt động. Để có đầy đủ chức năng, tôi đã muốn dùng thử ScaleArc trong một thời gian. Nó trông giống như một công cụ thực sự khéo léo để nhân rộng và khả năng phục hồi trong thế giới Máy chủ SQL.
• Đặt máy chủ trong các trang web của khách hàng của bạn là một công thức cho một thảm họa không thể kiểm soát được trừ khi bạn có chiến lược triển khai đẳng cấp thế giới (dựa trên mô tả về việc di chuyển của bạn, bạn chưa có). Đừng đẩy dịch vụ đám mây tại chỗ vì bạn gặp vấn đề về hiệu suất. Giải quyết các vấn đề về hiệu suất ngay bây giờ và sau đó bạn sẽ không phải đối phó với những vấn đề tốn kém hơn khi thực hiện.
• Máy chủ nhà nước của bạn nên là một cơ sở dữ liệu của một số loại. Thực hiện theo hướng dẫn HA của họ. Bạn có thể sử dụng SQL Server cho việc này, vì bạn đã có sẵn nó cho bạn.
• Nói về cơ sở dữ liệu, nhân rộng không cho phép HA. Trong thực tế, SQL Replication sẽ khiến bạn đau đầu trong mỗi lượt (nói từ kinh nghiệm với nhiều kịch bản sao chép nút). Phản chiếu có thể hoạt động, nhưng cuối cùng tôi nhớ, phân cụm SQL mất 1-5 phút để chuyển sang máy chủ mới. Tôi đã nghe những điều hay về Luôn luôn, nhưng tôi vẫn nghi ngờ về hồ sơ theo dõi của Microsoft. Một cái gì đó như ScaleArc có thể giúp đỡ nhiều hơn ở đây.
• Máy chủ web của bạn nên không trạng thái. Xoay ba hoặc bốn và đặt chúng phía sau một bộ cân bằng tải. Điều đó giải quyết những lo lắng về thời gian hoạt động của bạn ở đó. Như Frederik đã đề cập trước đó, bạn cũng có thể thực hiện triển khai theo cách này.
• Dịch vụ web của bạn có lẽ nên không trạng thái. Nếu không, hãy xem liệu bạn có thể chia nó thành các bit không trạng thái và trạng thái không. Đặt nhiều phiên bản của nó phía sau cùng một bộ cân bằng tải một lần nữa sẽ giải quyết được những lo lắng về thời gian hoạt động và cho phép các kịch bản triển khai được quan tâm hơn (ví dụ như triển khai màu xanh / xanh lục).

Không giống như Frederik, tôi sẽ không gọi chứng hoang tưởng đám mây của bạn là không chính đáng. Nó phụ thuộc vào yêu cầu thời gian hoạt động của bạn. Có thể hình dung rằng một dịch vụ sẽ phải chạy trong nhiều trung tâm dữ liệu được vận hành bởi các nhà cung cấp khác nhau ở các quốc gia khác nhau để dự phòng. Tuy nhiên, với trạng thái hiện tại của bạn, tôi đồng ý rằng AWS, Azure hoặc tương tự có thể là cược an toàn cho công ty của bạn.

Nhận một số mức HA trên lớp ứng dụng và web của bạn:

1. Lý tưởng nhất là đưa ra bất kỳ trạng thái nào, bao gồm trạng thái phiên vào các hệ thống trạng thái dùng chung như cơ sở dữ liệu hoặc máy chủ trạng thái phiên trong bộ nhớ. Tùy thuộc vào thiết kế ứng dụng của bạn, điều này có thể gây ra các vấn đề về hiệu suất do độ trễ thêm vào nhận được một lượng lớn trạng thái.

2. Mỗi trang web và tầng ứng dụng của bạn nên có một bộ cân bằng tải độc lập trước mặt chúng. NGINX sẽ thực hiện thủ thuật, nhưng IIS cũng có thể làm điều này (ARR).

3. Nếu một cơ sở dữ liệu không thể xử lý tải, hãy tận dụng phân vùng trạng thái phiên (hoặc băm hoặc băm nhất quán) để định tuyến yêu cầu cụ thể đến một hộp cơ sở dữ liệu cụ thể.

Nếu trạng thái bao thanh toán quá khó, bạn có thể đi với mối quan hệ máy chủ để cân bằng tải (tức là người dùng thường xuyên được chuyển đến cùng một hộp, thường dựa trên cookie). Nó không khả dụng cao như cách tiếp cận vòng tròn không trạng thái, bởi vì việc ngừng hoạt động của hộp sẽ ảnh hưởng đến tất cả người dùng và trạng thái trên hộp đó, nhưng nó hoàn toàn mất điện (phụ thuộc vào trường hợp sử dụng).

Về phía nâng cấp:

1. Thiết kế các tập lệnh cơ sở dữ liệu của bạn theo cách mà việc nâng cấp cơ sở dữ liệu có thể được thực hiện trong khi hệ thống đang chạy, nói cách khác, duy trì khả năng tương thích ngược. Một mô hình hoạt động tốt cho điều đó là "mở rộng, sau đó ký hợp đồng" -> chỉ thực hiện các thay đổi tương thích ngược, tương thích ngược nhưng loại bỏ các phụ thuộc vào các trường (v.v.) mà bạn muốn loại bỏ; sau đó nâng cấp tất cả các máy khách của cơ sở dữ liệu lên v-mới nhất; sau đó thực hiện nâng cấp db khác để loại bỏ các trường cũ (vv) trong cơ sở dữ liệu. Đây có thể là một quá trình chậm nếu bạn có một cơ sở dữ liệu lớn và bạn phải cẩn thận để không làm giảm hiệu suất của hệ thống.

2. Nâng cấp tầng ứng dụng của bạn: vì bạn không sử dụng môi trường đám mây, tôi khuyên bạn nên theo mô hình triển khai canary: thực hiện nâng cấp cuộn các hộp web & tầng giữa của bạn. Nếu việc triển khai bị trục trặc, hãy lấy hộp ra khỏi bộ cân bằng tải, giống như bạn làm như thể nó đã thất bại.

Lời cảnh báo: phát triển một hệ thống chưa được thiết kế cho HA thành một hệ thống có thể là một quá trình lâu dài và tốn kém. Bạn sẽ phải đánh đổi trên đường đi (chi phí so với nỗ lực để đạt đến một mức độ sẵn có cụ thể)

Chứng hoang tưởng trên đám mây của bạn là không có cơ sở - các nhà cung cấp như AWS kết hợp với thực hành tốt về phía bạn có thể kiểm soát / giảm thiểu hầu hết các rủi ro - hãy xem trang tuân thủ của họ để cảm nhận về những quy định mà họ tuân thủ: https: // aws .amazon.com / tuân thủ /

TL; DR: Xây dựng dự phòng, mô-đun; kiểm tra tính khả dụng; giám sát chặt chẽ.

Sau khi nhận ra rằng cố gắng vắt kiệt mọi lời giải thích có thể sẽ rất lâu nên tôi sẽ viết ra tất cả những quan sát tôi đã thực hiện.

Đặt câu hỏi tiền đề

Hệ thống đám mây là thuốc chữa bách bệnh

Ngay cả khi bạn đã đi hoàn toàn trên đám mây, với một nhà cung cấp đám mây hàng đầu, bạn vẫn sẽ cần thiết kế ứng dụng của mình để phục hồi, căn cứ. AWS có thể thay thế VM của bạn, nhưng ứng dụng của bạn sẽ có khả năng khởi động lại nếu để ở giữa tính toán.

Chúng tôi không muốn sử dụng hệ thống đám mây, vì x / y / z

Trừ khi bạn là một tổ chức cực lớn, bạn sẽ tốt hơn khi sử dụng các hệ thống đám mây. Top-3 hệ thống đám mây (AWS, MSFT, Google), sử dụng hàng ngàn kỹ sư để cung cấp cho bạn SLA đã hứa và bảng điều khiển dễ quản lý. Nó thực sự là một món hời tốt để sử dụng chúng thay vì dành một xu cho nhà này.

Các vấn đề trong phạm vi và thiết kế

Xác định, định lượng và sau đó liên tục đo lường sự sẵn có của một dịch vụ là một thách thức lớn hơn so với việc viết giải pháp cho các vấn đề về tính khả dụng.

Xác định và đo lường 'tính sẵn sàng' khó hơn dự kiến

Nhiều bên liên quan có quan điểm khác nhau về tính khả dụng và điều có thể xảy ra là định nghĩa được ưa thích bởi một người có mức lương cao nhất vượt qua định nghĩa khác. Điều này đôi khi là định nghĩa chính xác, nhưng thường thì hệ sinh thái không được xây dựng xung quanh việc đo lường điều tương tự bởi vì định nghĩa lý tưởng đó rất khó đo lường, hãy để một mình theo dõi trong thời gian thực. Nếu bạn có một định nghĩa về tính khả dụng không thể theo dõi trong thời gian thực, bạn sẽ thấy dự án tương tự tự thực hiện lặp đi lặp lại với những điểm tương đồng kỳ lạ. Gắn bó với một cái gì đó có ý nghĩa và một cái gì đó có thể dễ dàng theo dõi.

Mọi người đánh giá thấp sự phức tạp của hệ thống luôn có sẵn.

Để giải quyết con voi trong phòng, hãy để tôi nói điều này: "Không có hệ thống đa máy tính nào có sẵn 100%, nó có thể trong tương lai nhưng không phải với công nghệ hiện tại." Ở đây theo công nghệ hiện tại, tôi đang đề cập đến việc chúng ta không thể gửi tín hiệu nhanh hơn tốc độ ánh sáng và những thứ như vậy. Tất cả các kỹ sư comp-sci đáng muối của họ đều biết các hạn chế tính toán phân tán , và hầu hết trong số họ sẽ không đề cập đến nó trong các cuộc họp, vì sợ họ sẽ trông giống như những người mới. Để bù đắp cho tất cả những người không đề cập đến các giới hạn điện toán phân tán, tôi sẽ nói, nó phức tạp nhưng không luôn tin tưởng vào máy tính .

Mọi người đánh giá quá cao khả năng của họ

Thật không may, tính khả dụng nằm trong danh mục, nơi bạn không biết bạn muốn gì nhưng bạn biết bạn không muốn gì. Đó là một chút phức tạp hơn mà 'biết điều muốn' như giao diện người dùng. Nó đòi hỏi một chút kinh nghiệm và nhiều việc đọc để học hỏi kinh nghiệm của người khác và một số điều nữa.

Xây dựng một hệ thống có sẵn từ cơ sở

Hãy chắc chắn rằng bạn sẽ truyền giáo cho mọi nhóm kiến ​​trúc và thiết kế về mức độ ưu tiên đúng của tính sẵn có như một yêu cầu hệ thống.

Các thuộc tính của hệ thống giúp đỡ sẵn có

Các đặc điểm hệ thống sau đây đã cho thấy đã góp phần vào tính khả dụng của hệ thống:

Dư

Một số ví dụ về điều này là không bao giờ chỉ có một VM phía sau VIP hoặc không bao giờ chỉ lưu trữ một bản sao dữ liệu của bạn. Đây là những câu hỏi mà một IAAS tốt sẽ giúp bạn dễ dàng giải quyết hơn nhưng bạn vẫn sẽ phải đưa ra những quyết định này.

Tính mô đun

Một mô-đun REST tốt hơn so với SOA nguyên khối. Một microservice mô-đun thậm chí thực sự có sẵn nhiều hơn HATEOS REST thông thường . Lý do có thể được tìm thấy trong cuộc thảo luận liên quan đến Yield trong phần tiếp theo. Nếu bạn đang thực hiện xử lý hàng loạt thì tốt hơn là xử lý theo lô trong 10 giây hợp lý so với xử lý một lô 1.000.000.

Khả năng phục hồi

"I am always angry"
                    - Hulk

Một hệ thống đàn hồi luôn sẵn sàng để phục hồi. Khả năng phục hồi này áp dụng cho các trường hợp như thừa nhận ACK chỉ ghi sau khi ghi vào đĩa RAID và có thể qua ít nhất hai trung tâm dữ liệu. Một xu hướng mới nhất khác là sử dụng các cấu trúc dữ liệu không xung đột , trong đó cấu trúc dữ liệu chịu trách nhiệm giải quyết xung đột khi được trình bày với hai phiên bản khác nhau. Một hệ thống không thể phục hồi như một suy nghĩ sau, nó phải được dự đoán và tích hợp. Một thất bại được đảm bảo trong thời gian dài, vì vậy chúng ta nên luôn sẵn sàng với một kế hoạch để phục hồi.

Nhật ký đường mòn

Về mặt kỹ thuật, đây là một kiểu con của Khả năng phục hồi, nhưng là một thứ rất đặc biệt vì nó nắm bắt được tất cả các khả năng. Mặc dù nỗ lực tốt nhất, chúng tôi có thể không dự đoán được mô hình không có sẵn. Nếu có thể, hãy duy trì đủ số lượng nhật ký của các hoạt động hệ thống để có thể phát lại các sự kiện hệ thống. Điều này sẽ, với chi phí thủ công lớn, cho phép bạn phục hồi từ các tình huống không lường trước.

Thuộc tính sẵn có

Danh sách thuộc tính hàng đầu không đầy đủ về 'tính khả dụng': Để thảo luận, hãy giả sử câu hỏi mà người dùng hỏi là "Tôi có bao nhiêu mặt hàng trong giỏ hàng của mình?"

Đúng

Bạn có phải đưa ra câu trả lời chính xác nhất có thể hay không, có ổn không? Chỉ để tham khảo, khi bạn rút tiền từ ATM, nó không được đảm bảo là chính xác. Nếu ngân hàng phát hiện ra lỗi, có thể bạn sẽ đảo ngược các giao dịch. Nếu hệ thống của bạn đang tạo ra các số nguyên tố, thì tôi đoán, bạn có thể muốn câu trả lời đúng mọi lúc.

Năng suất

Bỏ qua điểm này, nếu bạn trả lời luôn đúng cho câu hỏi chủ đề trước. Đôi khi, câu trả lời cho các câu hỏi không cần phải chính xác, ví dụ tôi có bao nhiêu bạn bè trên Facebook ngay bây giờ? Nhưng câu trả lời dự kiến ​​sẽ ở trong sân bóng +/- 1 mọi lúc. Khi bạn đang tạo ra kết quả mong đợi, năng suất của bạn là 100.

Tính nhất quán

Câu trả lời của bạn có thể đúng vào một thời điểm, nhưng vào thời điểm ánh sáng rời khỏi màn hình và đi vào võng mạc của người quan sát, mọi thứ có thể đã thay đổi. Nó làm cho câu trả lời của bạn sai? Không, nó chỉ làm cho nó không nhất quán. Hầu hết các ứng dụng là nhất quán cuối cùng, nhưng mẹo là xác định loại mô hình nhất quán mà ứng dụng của bạn sẽ cung cấp. Nếu tình cờ ứng dụng của bạn có thể chạy trên một máy tính, bạn có thể bỏ qua cách đọc đáng yêu này trên định lý CAP .

Giá cả

Rất nhiều phụ thuộc vào tổng tác động của các tác động ngắn hạn (mất doanh thu) và các tác động dài hạn (danh tiếng xấu, giữ chân khách hàng). Tùy thuộc vào loại khách hàng (trả tiền / miễn phí, lặp lại / duy nhất, bị giam cầm) và tính sẵn có của tài nguyên, các mức đảm bảo sẵn có khác nhau sẽ được xây dựng.

Hướng tới cải thiện tính khả dụng của một hệ thống hiện có

Quản lý vận hành các máy riêng lẻ và mạng rất phức tạp, tôi cho rằng bạn đã để lại cho nhà cung cấp đám mây hoặc bạn đã đủ chuyên môn để biết bạn đang làm gì. Tôi sẽ chạm vào các chủ đề khác trong tình trạng sẵn có. Đối với chiến lược dài hạn Xác định-Đo lường-Phân tích-Kiểm soát là một trận đấu tuyệt vời, một cái gì đó tôi đã nhìn thấy bản thân mình.

1. Xác định "tính khả dụng" cho các bên liên quan của bạn là gì
2. Làm thế nào bạn sẽ đo lường những gì bạn đã xác định
3. Phân tích nguyên nhân gốc rễ để xác định tắc nghẽn
4. Nhiệm vụ cải tiến
5. Giám sát liên tục ( kiểm soát ) hệ thống

Nguyên nhân không có sẵn

Vì chúng tôi đồng ý rằng quản lý vận hành sẽ bao gồm bất kỳ quản lý cơ sở hạ tầng vật lý nào, nên được thực hiện bởi các chuyên gia, tôi sẽ chạm vào các nguyên nhân khác của sự không sẵn sàng vì lợi ích hoàn chỉnh. Tính khả dụng của IMO cũng nên bao gồm thiếu hành vi dự kiến, nghĩa là nếu người dùng không được hiển thị trải nghiệm mong đợi, thì điều gì đó không khả dụng. Với định nghĩa rộng rãi đó, những điều sau đây có thể gây ra sự không khả dụng: - Lỗi mã - Sự cố bảo mật - Vấn đề về hiệu suất