Bài viết được sự cho phép của tác giả Edward Thiên Hoàng
Xem lại phần 1
4. THIẾT KẾ VÀ TỐI ƯU HÓA ỨNG DỤNG
Thiết kế của ứng dụng hoặc phần mềm đóng một vai trò lớn trong việc lập dự toán công suất. Nếu một session được tạo cho mỗi người dùng đồng thời, điều này có nghĩa là mức tiêu thụ bộ nhớ cho mỗi session. Đối với mỗi hoạt động, các yếu tố như kết nối cơ sở dữ liệu, số lượng object được lưu trữ trong bộ nhớ và lượng xử lý diễn ra sẽ xác định dung lượng bộ nhớ và dung lượng xử lý cần thiết. Các ứng dụng được thiết kế tốt sẽ cố gắng giữ cho những con số này ở mức thấp hoặc sẽ chia sẻ tài nguyên của hiệu quả. Số lượng tài nguyên được tạo ra cho một ứng dụng cũng đóng một vai trò. Ví dụ, đối với các hoạt động chuyên sâu của cơ sở dữ liệu, kích thước nhóm kết nối cơ sở dữ liệu sẽ là một yếu tố hạn chế. Tương tự, thread pool, thời gian thu gom rác, v.v. cũng xác định hiệu năng của hệ thống. Việc thử và thử nghiệm chịu tải ứng dụng bằng các công cụ (ví dụ: đối với các ứng dụng Java, JProiler, JConsole, JMeter, v.v.) sẽ giúp xác định các điểm tắc nghẽn trong ứng dụng.
Các tham số tối ưu hóa cũng nên được tính đến như một phần của giải pháp. Các kỹ thuật như bộ nhớ đệm có thể giúp cải thiện hiệu suất và độ trễ – điều này cần được xem xét từ góc độ rộng hơn. Nếu các phản hồi của dịch vụ thay đổi thường xuyên, thì bộ nhớ đệm sẽ không tạo ra quá nhiều sự khác biệt. Bộ nhớ cache thời gian làm nóng cũng cần phải được tính đến.
Cũng khuyến khích để có một dung lượng buffer khi phân bổ các thông số máy chủ. Ví dụ, phân bổ thêm 20-30% thông số kỹ thuật của máy chủ cho các NFR cao điểm để đảm bảo hệ thống không hết dung lượng khi tải tối đa.
Cũng nên dùng các công cụ giám sát để tính toán công suất hệ thống. Thử nghiệm chịu tải, ứng dụng và máy chủ profiling thông qua các công cụ giám sát và profiling có thể giúp xác định công suất hiện tại khá chính xác và giúp xác định trước các điểm tắc nghẽn.
Loại phần cứng cũng là điểm khác biệt. Các máy vật lý truyền thống đang nhanh chóng được thay thế bởi VM và các Cloud. Cách lý tưởng để tính công suất là có điểm chuẩn trên các môi trường khác nhau này. Cấp phát bộ nhớ 4GB trên máy ảo có thể không giống với phân bổ bộ nhớ 4GB trên máy chủ vật lý hoặc phiên bản Amazon EC2. Cũng có những trường hợp hướng đến một số loại hoạt động nhất định. Ví dụ, EC2 có các trường hợp được tối ưu hóa bộ nhớ, tính toán tối ưu hóa hoặc tối ưu hóa I/O dựa trên loại hoạt động chính.
5. TÍNH SẴN SÀNG CAO VÀ KHẢ NĂNG MỞ RỘNG
5.1 KHẢ NĂNG MỞ RỘNG
Khả năng mở rộng là khả năng xử lý các yêu cầu tương ứng với tài nguyên phần cứng có sẵn; một hệ thống có thể mở rộng lý tưởng nên xử lý tăng / giảm yêu cầu mà không ảnh hưởng đến thông lượng chung.
Khả năng mở rộng có hai trường phái; mở rộng theo chiều dọc (vertical scaling) tăng hiệu suất của máy chủ bằng cách tăng bộ nhớ, sức mạnh xử lý, v.v. (ví dụ: chênh lệch hiệu suất giữa máy chủ RAM 4GB và máy chủ RAM 8GB) so với khả năng mở rộng theo chiều ngang (horizontal scaling) hoặc Mở rộng quy mô, nơi bạn triển khai thêm nhiều máy chủ cùng loại.
Dựa trên các yêu cầu về tính khả dụng đã thảo luận ở trên, chúng ta cần xác định mô hình sẵn sàng cao phù hợp. Tính sẵn sàng cao có thể được phân loại như sau:
5.2 TÍNH SẴN SÀNG CAO
Tính sẵn sàng cao có thể đạt được thông qua phương thức active-active, hoặc chuyển đổi dự phòng active-passive. Trong cách đầu tiên, tính khả dụng khá cao trong khi kịch bản thứ hai, chuyển đổi dự phòng sang node thụ động cần can thiệp thủ công hoặc tự động. Tùy thuộc vào điều này, sự sẵn có của sau này sẽ giảm.
Figure 7: High Availability Within a Data Center
Phân cụm (Clustering) là một kỹ thuật phổ biến để đạt được tính sẵn sàng cao bằng cách cung cấp dự phòng ở cấp độ phần mềm và phần cứng (Hình 7). Thông thường có 4 điều kiện khác nhau có thể được sử dụng ở đây:
- Chế độ chờ lạnh (Cold-standby): Trong thiết lập này, node chính đang hoạt động và node phụ là node thụ động. Node phụ là bản sao lưu giống hệt của node chính, nhưng chỉ được cài đặt và khởi động (cả phần cứng và thành phần phần mềm của máy chủ) nếu node chính bị lỗi. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là cần thời gian khá lâu.
- Chế độ chờ ấm (Warm-standby): Trong thiết lập này cũng là node chính đang hoạt động và node phụ là node thụ động. node phụ là một bản sao lưu giống hệt của node chính và các thành phần phần mềm cần thiết được cài đặt, nhưng không chạy. Node máy chủ vật lý đang chạy mặc dù và trong trường hợp xảy ra lỗi node chính, các thành phần phần mềm trên node phụ được khởi động. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là một vài phút.
- Chế độ chờ nóng (Hot-standby): Trong thiết lập này một lần nữa, node chính được kích hoạt và node phụ là node thụ động. node phụ là một bản sao lưu giống hệt của node chính và các thành phần phần mềm cần thiết được cài đặt; và máy chủ vật lý và tất cả các thành phần phần mềm đang chạy. Tuy nhiên, node phụ không chấp nhận bất kỳ request nào và chỉ bắt đầu làm như vậy trong trường hợp lỗi node chính. Do đó, thời gian phục hồi để đưa node phụ trực tuyến và hoạt động sẽ là một vài giây.
- Active-active: Cả hai node đang chạy và xử lý các yêu cầu song song. Ở đây, vì cả hai node chấp nhận yêu cầu, không có khái niệm thời gian phục hồi và cân bằng tải là tức thời.
Tính sẵn sàng cao cũng có thể đạt được thông qua các xem xét kiến trúc bổ sung như:
- Cân bằng tải và định tuyến – cân bằng các yêu cầu của khách hàng giữa các node; các kỹ thuật, chẳng hạn như session affinity, có thể được sử dụng để định tuyến các yêu cầu từ cùng một session đến cùng một node
- Phân cụm – cho phép tất cả các thành phần trong cụm được xem như là một đơn vị chức năng duy nhất
- Sao chép trạng thái – sao chép trạng thái của một máy chủ trong số các máy chủ khác có thể hoạt động trơn tru trong trường hợp chuyển đổi dự phòng
- Hệ thống tự mở rộng – cho phép tự động mở rộng các server tùy thuộc vào yêu cầu
- Hệ thống tự hồi phục – tự động khởi động lại hệ thống thông qua giám, v.v. cho phép các hệ thống không khả dụng tự phục hồi
5.3 PHỤC HỒI SAU THẢM HỌA (DISASTER RECOVERY)
Phục hồi thảm họa (DR) liên quan đến việc sao chép hệ thống chính lên một vùng riêng biệt về mặt địa lý để hệ thống có thể phục hồi khi hệ thống chính bị hỏng.
5.4 SAO LƯU VÀ PHỤC HỒI
Sao lưu và phục hồi liên quan đến việc sao chép ứng dụng, trạng thái hệ thống và ứng dụng và dữ liệu hệ thống lên phương tiện sao lưu. Điều này sau đó có thể được phục hồi do lỗi hệ thống chính hoặc do ứng dụng đạt đến trạng thái không nhất quán.
5.5 CLOUD
Đám mây cho phép các máy chủ được triển khai ở các vị trí địa lý khác nhau với các mạng tốc độ cao giữa các vị trí địa lý. Chẳng hạn, Amazon EC2 cho phép các máy chủ được triển khai trong một availability zone, cross zone hoặc thậm chí cross region, do đó cung cấp một cách thức rất dễ tiếp cận để đạt được tính sẵn sàng cao, toàn diện.
6. TÍNH TOÁN CÔNG SUẤT
Trên đây chỉ là một vài yếu tố có thể được sử dụng để lập dự toán công suất của một hệ thống và tầm quan trọng của các yếu tố này thay đổi dựa trên loại môi trường.
Các kiến trúc sư khác nhau sử dụng các quy trình khác nhau để tính toán công suất. Một quy trình mẫu được minh họa trong Hình 6; bất kể quá trình nào, nó cần được kết hợp với quy trình kiến trúc giải pháp hiện có của bạn.
Figure 8: Capacity Planning as Part of Deployment Architecture Process
Theo quy trình trong Hình 8, điều quan trọng là phải có một kiến trúc kinh doanh chính xác có thể được chuyển đổi thành kiến trúc giải pháp cấp cao. Dựa trên điều này, nhóm có thể bắt đầu thu thập dữ liệu dung lượng sẽ được sử dụng để tạo ra ma trận hoặc mô hình lập dự toán công suất.
Với các yếu tố này, chúng ta cũng cần một bộ số hiệu suất chuẩn để tính công suất máy chủ. Ví dụ, nếu chúng ta biết rằng một server trong các điều kiện môi trường nhất định với loại công suất nhất định hoạt động ở 3000 TPS, thì chúng ta có thể giả sử rằng một máy chủ có công suất và hoạt động tương tự sẽ cung cấp như nhau.
Tuy nhiên, điều quan trọng là phải hiểu rằng trong khi các điểm chuẩn có thể được sử dụng làm mô hình tham chiếu, thì khả năng áp dụng các số này cho vấn đề của bạn có thể khác nhau; do đó, ngoài khả năng dự báo, điều quan trọng là phải kiểm tra môi trường để xác định công suất cực đại của nó.
7. KẾT LUẬN
Không nghi ngờ gì nữa, lập dự toán công suất là một nghệ thuật cũng như khoa học và rõ ràng kinh nghiệm đóng vai trò quan trọng trong việc lập kế hoạch chính xác về năng lực. Trong bài này, chúng ta đã xem xét các khái niệm khác nhau về lập dự toán công suất và cách chúng ảnh hưởng đến năng lực giải pháp của hệ thống. Good luck!
8. THAM KHẢO
https://wso2.com/whitepapers/capacity-planning-for-application-design-part-1/
Article: ESB Performance Benchmark, Round 7.5
https://wso2.com/library/articles/2014/02/esb-performance-round-7.5/
Whitepaper: WSO2 Carbon Product Performance and Deployment Topology Sizing
https://wso2.com/whitepapers/wso2-carbon-product-performance-and-deploymenttopology-sizing/
Blog: How to measure the peformance of a server:
http://srinathsview.blogspot.com/2012/05/how-to-measure-performance-of-server.html
Bài viết gốc được đăng tải tại edwardthienhoang.wordpress.com
Có thể bạn quan tâm:
- Capacity Planning – Dự toán công suất cho ứng dụng (Tập 1 )
- 5+ ứng dụng cải thiện hiệu suất công việc và quản trị nhân sự
- Python cơ bản cho ứng dụng trong công việc
Xem thêm Việc làm Developer hấp dẫn trên TopDev
