Một số hỏi đáp liên quan đến OpenStack từ Summit HongKong 2013



style=”display:inline-block;width:300px;height:250px”
data-ad-client=”ca-pub-6542082644751886″
data-ad-slot=”6823820859″>

Đây là một số câu hỏi bên mình gởi gắm các anh công ty DTT trước chuyến Summit HongKong 2013. Các câu hỏi được tham khảo và chia sẻ bởi các chuyên gia trong chuyến Summit.

1. Số lượng Controller node? Khi nào thì cần thêm Controller?

Theo kiến trúc best practice của Cisco và theo lời khuyên của chuyên gia hãng Mirantis, nên dùng ít nhất 3 controller node cho mỗi hệ thống điện toán đám mây. Trong các dịch vụ thì có dịch vụ có thể cấu hình HA dạng active/active (load balancing) nhưng cũng có dịch vụ phải cấu hình dạng active/standby. Kiến trúc của Cisco cho phép cấu hình HA hầu hết các dịch vụ dạng active/active (trừ L3 agent, cái này sẽ đề cập sau). Cisco sử dụng Galera để cấu hình HA dạng multi-master cho MySQL, tuy nhiên kiến trúc này có thể dẫn tới deadlock như chia sẻ của chuyên gia một hãng khác (có thể khắc phục bằng cấu hình one-write, multi-read). Cũng có thể deadlock khó xảy ra ở quy mô hiện tại của DC.

Câu hỏi khi nào cần thêm Controller không có câu trả lời chính xác. Tuy nhiên, theo chia sẻ của chuyên gia trung tâm CERN, họ đang vận hành một hệ thống điện toán đám mây với 2 private cloud, mỗi cloud có khoảng 10.000 cores thì họ cũng bắt đầu với 3 controller cho mỗi cloud này. Khi hỏi một chuyên gia của hãng khác, họ nói 3 controller node có thể đáp ứng tốt việc start/stop cùng lúc 200 VM và thực tế họ đã cấu hình một vài hệ thống tới 400 VM với 3 Controller.

2. Networking trong OpenStack

Các Production trên thế giới sử dụng Switch để thiết kế OpenStack networking (Neutron) hay sử dụng máy chủ như trong tài liệu guide của OpenStack?

Hệ thống của CERN – 20.000 cores vẫn đang chạy Nova-network tức sử dụng máy chủ. Rackspace nói họ vẫn đang sử dụng nova-network cho các hệ thống production bởi theo họ quantum/neutron chưa sẵn sàng cho production.

Neutron từ phiên bản Grizzly cho phép phân bố các router ảo trên nhiều node nhưng bản thân nó không hỗ trợ HA (1 network chỉ có duy nhất 1 L3 agent được phép chạy). Tuy có thể cấu hình HA cho L3 agent trong neutron dạng active/passive sử dụng Peacemaker nhưng mô hình này không dễ mở rộng. L3-agent HA active/active hiện mới có ở dạng concept (http://telekomcloud.github.io/2013/06/10/openstack-networking-high-availability.html).

Hệ thống 6.400 node của trường ĐH quốc phòng TQ (chạy trên siêu máy tính Tienhe-2) sử dụng 90 node làm networking (Neutron). Một câu hỏi trong mailling list của Openstack (ngày 27-9) về việc sử dụng quantum/neutron trong production nhưng không nhận được bất cứ câu trả lời nào (http://lists.openstack.org/pipermail/openstack-operators/2013-September/003584.html). Đáng chú ý, người gửi câu hỏi là Scott Devoid đang làm việc tại Argonne National Laboratory khẳng định đã sử dụng Diablo và Essex cùng với nova-network cho các hệ thống production – 600 máy – được vài năm.

Như vậy có thể khẳng định việc dùng máy chủ làm networking là thông dụng.

Cisco có Nexus plugin cho các dòng Switch Cisco Nexus sử dụng cho OpenStack, hiện tại các production có sử dụng phương án này không?

Nexus plugin cho Cisco switch có thể giúp chuyển việc cấu hình L3 HA lên switch (tức cấu hình HA trên switch vật lý) và cũng là 1 option nên xem xét vì DSP có Switch Cisco Nexus 7000 hỗ trợ plugin này. Tuy nhiên cũng cần chú ý là nếu dùng switch vật lý với plugin cho Openstack networking thì có thể không upgrade lên được phiên bản mới (vì có thể plugin mới không hỗ trợ Nexus 7000). Hơn nữa, xu thế Openstack sử dụng software defined networking (liên kết mạng định nghĩa bằng phần mềm) là rất rõ ràng nên vấn đề với L3 agent sẽ sớm được giải quyết.

3. Triển khai Cinder và Swift

Phương án triển khai partitioning của các máy chủ compute và controller như thế nào?

Câu hỏi này về partition layout cho HDD? Parition layout trên controller và compute node không quá quan trọng, hơn nữa nếu cài đặt LVM thì việc thay đổi dung lượng cho các partition nếu cần là hoàn toàn khả thi.

Phương án triển khai các máy chủ lưu trữ của Swift? Sử dụng máy chủ đặc dụng lắp rất nhiều HDD, hay sử dụng các PC thông thường (lắp nhiều HDD), …

Trong các hệ thống production thì không ở đâu sử dụng PC để làm storage (mặc dù hoàn toàn có thể). Tuy Object storage như swift sẽ tự động nhân bản dữ liệu để đảm bảo tính toàn vẹn trong trường hợp 1 số máy vật lý hỏng nhưng sử dụng máy chủ sẽ ít lỗi hơn. Các hệ thống lưu trữ object storage có thể dùng máy chủ (không cần mạnh), gắn nhiều HDD (có thể dùng JBOD), các HDD thường là SATA, tốc độ chậm (5400rpm – 7200rpm) và dung lượng lớn.

Nếu triển khai Swift thì sử dụng bao nhiêu Swift proxy là phù hợp? Cách tính như thế nào?

Trong mô hình 13 máy của Cisco, họ dùng 2 máy làm proxy và 3 máy làm lưu trữ. Tuy nhiên số lượng bao nhiêu máy làm proxy thì cần thử nghiệm xem nhu cầu truy cập dữ liệu lớn tới đâu.

Một xu hướng rất mạnh và được nói tới nhiều trong kì summit này là dùng Ceph làm hệ thống lưu trữ đơn nhất cho cả cloud. Theo ý kiến của chúng tôi, nên dùng Ceph thay cho Swift vì Ceph hỗ trợ cả block, object và filesystem. Ceph có thể dùng làm backend storage cho Glance, Cinder và lưu trữ instance (cho Live migration). Hệ thống thực tế dùng Ceph có thể kể tới là hệ thống 6.400 node của ĐH quốc phòng TQ, private cloud của CERN và hệ thống do DELL triển khai tại ĐH ALABAMA AT BIRMINGHAM dùng Ceph làm kho lưu trữ tốc độ cao cho cả HPC và cloud. Tuy nhiên cần chú ý là Ceph không hỗ trợ nhân bản dữ liệu giữa các DC như Swift.

4.    Nên thiết kế OpenStack như thế nào khi các máy chủ bao gồm Blade server và Rack server? Controller nên dùng blade server hay rack? Compute nên dùng blade hay rack server?

Câu hỏi này theo chuyên gia Mirantis là không quan trọng, dùng server dạng nào cho Compute, Controller đều được. Tuy nhiên theo ý kiến của chúng tôi, nên dùng server có nhiều CPU cores và RAM làm compute node.

5.    Các distro linux sử dụng để triển khai OpenStack, là Ubuntu phiên bản mấy (quan trọng), CentOS phiên bản mấy, RedHat phiên bản mấy?

Các hệ thống production được triển khai khá lâu nên cũng sử dụng nhiều phiên bản HĐH khác nhau. Nếu dùng Ubuntu thì nên sử dụng bản LTS vì thời gian hỗ trợ dài hơn (bản 12.04 LTS được hỗ trợ tới 2017). Hệ thống 6.400 node nói trên sử dụng Ubuntu 12.04 LTS, CERN dùng SLC6 (Science Linux Cern 6 xây dựng dựa trên RHEL6), kiến trúc được chứng nhận của Cisco sử dụng RHEL6.4.

Theo kết quả điều tra người sử dụng thực hiện bởi OpenStack Foudation tháng 10 vừa rồi thì có tới hơn 55% stack triển khai trên Ubuntu, tiếp theo là Centos 24% và RHEL 10% (http://www.openstack.org/blog/2013/11/openstack-user-survey-october-2013/). Tuy kết quả điều tra này bao gồm cả các hệ thống production và PoC nhưng có thể khẳng định Ubuntu vẫn chiếm phần lớn trong các hệ thống production.

Phiên bản triển khai production đang sử dụng là phiên bản nào? Essex, Folsom, hay Havana?

CERN có hệ thống pre-production chạy Folsom, hiện tại hệ thống production đang chạy Grizzly. Hệ thống 6.400 node nói trên, cloud của Paypal, Rackspace … đều đang sử dụng Grizzly. HP đã bắt đầu cung cấp public cloud trên nền Havana; Rackspace mới tuyên bố Havana private cloud nhưng nói rõ là hệ thống này chưa nên sử dụng cho production. Ngoài ra vẫn còn khá nhiều hệ thống production đang chạy Essex và Folsom (http://www.slideshare.net/openstack/openstack-user-survey-october-2013).

Có 1 case study khá thú vị là hệ thống OpenStack Grizzly 6.400 node của ĐH Quốc Phòng TQ được sử dụng để triển khai e-Gov cho thành phố Quảng Châu với 2 dịch vụ chính: Websites of Guangzhou government (Web/Application/Database servers) và e-Gov Data Management System (JBoss/Weblogic/Oracle servers).

Việc upgrade các phiên bản của OpenStack khi có phiên bản OpenStack mới như thế nào? Ví dụ đang cung cấp dịch vụ production sử dụng Grizzly, nâng cấp lên phiên bản mới Havana như thế nào?

Hiện vẫn chưa có giải pháp nào cho phép nâng cấp phiên bản OpenStack một cách “trơn tru”. Chuyên gia các hãng vẫn khuyên nếu nâng cấp thì làm dần, thiết lập hệ thống với phiên bản mới, rồi chuyển dần các VM và server vật lý từ hệ thống cũ sang hệ thống mới sau khi đã chắc chắn các VM hoạt động tốt. Rackspace hiện đã triển khai Havana cho Private cloud nhưng vẫn duy trì các software trên hệ thống cũ chạy Grizzly để đảm bảo các dịch vụ thông suốt.

6. Security trong OpenStack (option)

Bài trình bày của Brian Chong – Symantec khá đầy đủ về việc thiết kế hệ thống OpenStack đảm bảo security thế nào, từ message queue, network segmentation đến các API.

http://www.openstack.org/summit/openstack-summit-hong-kong-2013/session-videos/presentation/security-on-openstack

7. Các vấn đề khác

Một vấn đề quan trọng khác cần chú ý khi triển khai OpenStack là automation (tự động hoá tiến trình triển khai). OpenStack có rất nhiều thành phần và việc cài đặt, cấu hình, đồng bộ hoá để đưa OpenStack vào hoạt động tốn rất nhiều công sức và thời gian. Có rất nhiều công cụ được phát triển để tự động hoá tiến trình triển khai, trong đó có thể kể tới: Crowbar (DELL), Rackspace, PackStack, Foreman (RedHat), SaltStack, Puppet, Chef, TripleO, COI (cisco), Maas/JuJu (Canonical) và Fuel (Mirantis). Hãy điểm qua các công cụ này.

Crowbar được cung cấp bởi DELL và được thiết kế để hoạt động tốt nhất trên nền tảng phần cứng của DELL nên có thể không phù hợp với các phần cứng hãng khác.

Rackspace Private Cloud là phần mềm của Rackspace cho phép triển khai OpenStack trên các node đã cài sẵn OS nhưng không hỗ trợ cài đặt từ phần cứng – baremetal provisioning. Hơn nữa Rackspace mặc định sử dụng nova-network. PackStack cũng giống Rackspace ở điểm không triển khai được từ máy vật lý.

Foreman được phát triển bởi RedHat và dễ hiểu tại sao nó chỉ có thể triển khai OpenStack với RHEL, Centos hay Fedora làm host OS.

SaltStack, Puppet và Chef có 2 phiên bản cho Enterprise và mã mở với phiên bản mã mở thiếu hỗ trợ GUI và HA.

TripleO (OpenStack-on-OpenStack) là một dự án rất mới, hướng tới triển khai OpenStack trên chính nó, hiện vẫn đang ở dạng thử nghiệm là chủ yếu.

COI (Cisco Openstack Installer) là tool của CISCO hỗ trợ triển khai từ máy vật lý, hỗ trợ HA dạng active/active (trừ L3 agent) nhưng thiếu GUI và công cụ giám sát (monitoring). COI không hỗ trợ Ceph.

Maas/JuJu do Canonical phát triển và dùng để triển khai OpenStack trên Ubuntu từ máy vật lý. Maas/JuJu cung cấp cả GUI khá bắt mắt và CLI tuy nhiên không có thông tin về hệ thống production sử dụng giải pháp này.

Fuel là một dự án mã mở dẫn đầu bởi Mirantis. Fuel hỗ trợ triển khai OpenStack từ máy vật lý với khả năng hỗ trợ cấu hình rất linh hoạt. Người dùng có thể chọn HA cho tất cả các dịch vụ, có thể chọn OS cũng như bản phân phối OpenStack của RedHat hay Ubuntu. Fuel cung cấp cả giao diện Web (FuelWeb) và CLI với khả năng giám sát và kiểm thử tính năng hệ thống (ví dụ kiểm thử HA các dịch vụ). Fuel đã được sử dụng để triển khai các hệ thống production Cloud tại Paypal và NASA. Xem thêm tại http://software.mirantis.com/key-related-openstack-projects/project-fuel/.

Một điểm chú ý nữa, các công cụ trên đều hỗ trợ tốt Grizzly và chưa/không hỗ trợ triển khai Havana một cách toàn diện.

1 bình luận về “Một số hỏi đáp liên quan đến OpenStack từ Summit HongKong 2013

Bình luận