Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
Trong một hệ thống phân tán hiện đại ngày nay cùng với việc move lên Cloud thì có rất nhiều thuật ngữ, từ ngữ mô tả về hệ thống rất dễ gây nhầm lẫn như High Availability, Redundancy, Resiliency, Fault Tolerrance, Failover,… Hãy cùng phân tích và so sánh các thuật ngữ đó để có thể dùng chúng chính xác hơn trong từng ngữ cảnh.
HIGH AVAILABILITY – TÍNH SẴN SÀNG CAO
High Availability (HA) hay còn gọi là Tính Khả Dụng/Sẵn Sàng Cao. Từ này gặp rất nhiều khi làm việc với các Cloud Service để đề cập đến việc 1 hệ thống hay service đó có tỷ lệ sống sót là bao nhiêu % trong 1 khoảng thời gian. Ví dụ nếu nói hệ thống có HA = 99% thì tức là sẽ có downtime (thời gian chết) là 3.65 ngày trong 1 năm, 7.31 giờ trong một tháng, 14.4 phút trong 1 ngày. Thời gian downtime có thể là do hệ thống cần được tắt để bảo trì nâng cấp hoặc bị cúp điện chẳng hạn. Vậy làm thế nào để có thể tăng tính HA cho hệ thống? Ví dụ có 1 số service sẽ có SLA (Service Level Agreement) hay Cam kết chất lượng dịch vụ cho HA lên đến 9 số 9 ( 99.9999999%) hoặc như DNS service sẽ có HA = 100%. Tất nhiên để HA càng cao thì chi phí càng đắt. Do đó, trong mỗi hệ thống cần suy nghĩ xem HA bao nhiêu là vừa đủ. Để làm được điều này thì chúng ta sẽ cần áp dụng một số kỹ thuật như redundancy, replication, zero-downtime deployment, fail-over,…
RELIABILITY – ĐỘ TIN CẬY
Một hệ thống có độ tin cậy cao thì HA sẽ cao, nhưng ngược lại không đúng. 1 hệ thống có khả năng sẵn sàng cao không có nghĩa là một hệ thống ưu việt. Ví dụ có con server đang sống và nhận, xử lý request đều đều, bỗng dưng không hiểu vì sao mà thời gian xử lý request mỗi lúc một lâu, có khi timeout luôn. Thì khi đó mặc dù ta nói HA vẫn cao nhưng độ tin cậy lại thấp.
Thật ra khi làm system design, mình chỉ hay chú ý đến High availability mà ít khi nghĩ đến tính Reliability. Phần này mình sẽ dựa theo Reliability pillar, một trong 5 pillars được định nghĩa trong AWS Well-Architected Framework.
Reliability is the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.
Độ tin cậy là khả năng hệ thống phục hồi từ sự gián đoạn cơ sở hạ tầng hoặc dịch vụ, tự động có được tài nguyên điện toán để đáp ứng nhu cầu và giảm thiểu sự gián đoạn như cấu hình sai hoặc các sự cố mạng tạm thời.
Nói ngắn gọn là để đạt được độ tin cậy cao thì cần phải áp dụng rất nhiều kỹ thuật, mà nổi bật nhất trong đó là High Availability. Ngoài ra còn có họ còn khuyến khích:
- Triển khai tự động nhằm loại bỏ các yếu tố lỗi do con người.
- Kiểm thử tính khả dụng, chịu tải, giả lập các tình huống gây lỗi tìm phương hướng khắc phục.
- Cần giám sát hệ thống chặt chẽ và báo động, tìm giải pháp (tự động hoặc thủ công) nhằm khắc phục.
- Thường xuyên kiểm tra (audit) để tìm ra các khuyết điểm của hệ thống.
REDUNDANCY VÀ REPLICATION – DỰ PHÒNG VÀ SAO CHÉP
Redundancy thường được thể hiện bằng cách có nhiều hơn 1 node/process trong 1 system để nhằm đảm bảo khi có sự cố xảy ra trên 1 node thì vẫn còn node khác có thể tiếp tục handle request, quá trình này gọi là fail-over. Có nhiều kiểu thiết lập redundancy như active-active hay active-passive bao gồm Cold-standby, Warm-standby hoặc Hot-standby. Các bạn có thể xem lại ở bài trước để hiểu rõ hơn ưu nhược của 2 hình thức này.
Replication thì tất nhiên là phải bao gồm việc đầu tiên là thiết lập redundancy kèm với việc sao chép data qua các redundant node luôn. Điển hình như việc sao chép dữ liệu giữa active DB node với các standby/passive node. Hoặc sao chép dữ liệu vào các backup node nhằm tránh tình trạng bị mất dữ liệu.
Hoặc có thể là có thêm máy phát điện dự phòng cho trường hợp cúp điện cũng là 1 ví dụ để tăng tính HA, nếu servers được host on-premises
Tuy nhiên, việc thiết lập 2 hoặc nhiều hơn các node có thực sự giúp cho HA cao hay không thì còn tùy vào cách setup. Ví dụ văn phòng bị chập mạch đường truyền internet vô data center bị đứt thì có bao nhiêu server trong đó đi chăng nữa cũng vô phương cứu chữa. Khi lên Cloud thì với lợi thế global infrastructure của mình, các nhà cung cấp hạ tầng, dịch vụ cloud cũng offer nhiều lựa chọn hơn cho khách hàng, ví dụ như thiết lập redundancy và replication ở nhiều khu vực vật lý khác nhau (multi AZ, multi Region, multi continent), và đương nhiên là giá cả sẽ khác nhau.
FAIL-OVER – CHUYỂN ĐỔI DỰ PHÒNG
Việc backup nhiều server dự phòng thôi là chưa đủ, ví dụ khi 1 server sập, làm thế nào để server khác có thể tiếp tục th
Trong một hệ thống phân tán hiện đại ngày nay cùng với việc move lên Cloud thì có rất nhiều thuật ngữ, từ ngữ mô tả về hệ thống rất dễ gây nhầm lẫn như High Availability, Redundancy, Resiliency, Fault Tolerrance, Failover,… Hãy cùng phân tích và so sánh các thuật ngữ đó để có thể dùng chúng chính xác hơn trong từng ngữ cảnh.
HIGH AVAILABILITY – TÍNH SẴN SÀNG CAO
High Availability (HA) hay còn gọi là Tính Khả Dụng/Sẵn Sàng Cao. Từ này gặp rất nhiều khi làm việc với các Cloud Service để đề cập đến việc 1 hệ thống hay service đó có tỷ lệ sống sót là bao nhiêu % trong 1 khoảng thời gian. Ví dụ nếu nói hệ thống có HA = 99% thì tức là sẽ có downtime (thời gian chết) là 3.65 ngày trong 1 năm, 7.31 giờ trong một tháng, 14.4 phút trong 1 ngày. Thời gian downtime có thể là do hệ thống cần được tắt để bảo trì nâng cấp hoặc bị cúp điện chẳng hạn. Vậy làm thế nào để có thể tăng tính HA cho hệ thống? Ví dụ có 1 số service sẽ có SLA (Service Level Agreement) hay Cam kết chất lượng dịch vụ cho HA lên đến 9 số 9 ( 99.9999999%) hoặc như DNS service sẽ có HA = 100%. Tất nhiên để HA càng cao thì chi phí càng đắt. Do đó, trong mỗi hệ thống cần suy nghĩ xem HA bao nhiêu là vừa đủ. Để làm được điều này thì chúng ta sẽ cần áp dụng một số kỹ thuật như redundancy, replication, zero-downtime deployment, fail-over,…
RELIABILITY – ĐỘ TIN CẬY
Một hệ thống có độ tin cậy cao thì HA sẽ cao, nhưng ngược lại không đúng. 1 hệ thống có khả năng sẵn sàng cao không có nghĩa là một hệ thống ưu việt. Ví dụ có con server đang sống và nhận, xử lý request đều đều, bỗng dưng không hiểu vì sao mà thời gian xử lý request mỗi lúc một lâu, có khi timeout luôn. Thì khi đó mặc dù ta nói HA vẫn cao nhưng độ tin cậy lại thấp.
Thật ra khi làm system design, mình chỉ hay chú ý đến High availability mà ít khi nghĩ đến tính Reliability. Phần này mình sẽ dựa theo Reliability pillar, một trong 5 pillars được định nghĩa trong AWS Well-Architected Framework.
Reliability is the ability of a system to recover from infrastructure or service disruptions, dynamically acquire computing resources to meet demand, and mitigate disruptions such as misconfigurations or transient network issues.
Độ tin cậy là khả năng hệ thống phục hồi từ sự gián đoạn cơ sở hạ tầng hoặc dịch vụ, tự động có được tài nguyên điện toán để đáp ứng nhu cầu và giảm thiểu sự gián đoạn như cấu hình sai hoặc các sự cố mạng tạm thời.
Nói ngắn gọn là để đạt được độ tin cậy cao thì cần phải áp dụng rất nhiều kỹ thuật, mà nổi bật nhất trong đó là High Availability. Ngoài ra còn có họ còn khuyến khích:
- Triển khai tự động nhằm loại bỏ các yếu tố lỗi do con người.
- Kiểm thử tính khả dụng, chịu tải, giả lập các tình huống gây lỗi tìm phương hướng khắc phục.
- Cần giám sát hệ thống chặt chẽ và báo động, tìm giải pháp (tự động hoặc thủ công) nhằm khắc phục.
- Thường xuyên kiểm tra (audit) để tìm ra các khuyết điểm của hệ thống.
REDUNDANCY VÀ REPLICATION – DỰ PHÒNG VÀ SAO CHÉP
Redundancy thường được thể hiện bằng cách có nhiều hơn 1 node/process trong 1 system để nhằm đảm bảo khi có sự cố xảy ra trên 1 node thì vẫn còn node khác có thể tiếp tục handle request, quá trình này gọi là fail-over. Có nhiều kiểu thiết lập redundancy như active-active hay active-passive bao gồm Cold-standby, Warm-standby hoặc Hot-standby. Các bạn có thể xem lại ở bài trước để hiểu rõ hơn ưu nhược của 2 hình thức này.
Replication thì tất nhiên là phải bao gồm việc đầu tiên là thiết lập redundancy kèm với việc sao chép data qua các redundant node luôn. Điển hình như việc sao chép dữ liệu giữa active DB node với các standby/passive node. Hoặc sao chép dữ liệu vào các backup node nhằm tránh tình trạng bị mất dữ liệu.
Hoặc có thể là có thêm máy phát điện dự phòng cho trường hợp cúp điện cũng là 1 ví dụ để tăng tính HA, nếu servers được host on-premises
Tuy nhiên, việc thiết lập 2 hoặc nhiều hơn các node có thực sự giúp cho HA cao hay không thì còn tùy vào cách setup. Ví dụ văn phòng bị chập mạch đường truyền internet vô data center bị đứt thì có bao nhiêu server trong đó đi chăng nữa cũng vô phương cứu chữa. Khi lên Cloud thì với lợi thế global infrastructure của mình, các nhà cung cấp hạ tầng, dịch vụ cloud cũng offer nhiều lựa chọn hơn cho khách hàng, ví dụ như thiết lập redundancy và replication ở nhiều khu vực vật lý khác nhau (multi AZ, multi Region, multi continent), và đương nhiên là giá cả sẽ khác nhau.
FAIL-OVER – CHUYỂN ĐỔI DỰ PHÒNG
Việc backup nhiều server dự phòng thôi là chưa đủ, ví dụ khi 1 server sập, làm thế nào để server khác có thể tiếp tục thực hiện các công việc hiện thời. Đó là nhờ các kỹ thuật về fail-over (chuyển đổi dự phòng). Các kỹ thuật fail-over thì cũng khá nhiều, tuy nhiên với việc lên Cloud hoặc sử dụng các container management and orchestration platform như Kubernetes thì việc cần làm là thiết lập cấu hình như DB fail-over hoặc container replica thì có thể ngồi rung đùi rồi.
ực hiện các công việc hiện thời. Đó là nhờ các kỹ thuật về fail-over (chuyển đổi dự phòng). Các kỹ thuật fail-over thì cũng khá nhiều, tuy nhiên với việc lên Cloud hoặc sử dụng các container management and orchestration platform như Kubernetes thì việc cần làm là thiết lập cấu hình như DB fail-over hoặc container replica thì có thể ngồi rung đùi rồi.
Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com
Có thể bạn quan tâm:
- Mô hình State Machine trong Distributed Systems
- Vì sao SQL tốt hơn NoSQL? (Phần 2)
- Bài toán đồng thuận trong Distributed Systems
Xem thêm Việc làm Developer hấp dẫn trên TopDev
