Mặc dù có rất nhiều sự quan tâm, đầu tư lớn và thành công cộng đồng, chúng tôi đã thấy một số trường hợp các dự án OpenStack có thiện chí thất bại hoặc ít nhất được coi là một thất bại bởi những người đã tài trợ cho chúng. Khi các dự án OpenStack thất bại, chính công nghệ hiếm khi là nguyên nhân gốc rễ. Thomas Bittman tại Gartner đã chú ý đến xu hướng này và đã viết một bài đăng trên blog có ảnh hưởng với tiêu đề Tại sao các đám mây riêng không thành công? vào tháng 9 năm 2014.
Phát hiện của Bittman lặp lại nhiều kinh nghiệm của chúng tôi từ lĩnh vực này. Nói tóm lại, lý do mà hầu hết các dự án đám mây riêng đều thất bại là do những kỳ vọng không phù hợp đã được đặt ra ngay từ đầu và mục tiêu kinh doanh cho đám mây không được hiện thực hóa bởi kết quả cuối cùng.
Trước hết, việc triển khai OpenStack nên được xem là một khoản đầu tư có lợi nhuận và không phải là một dự án để giảm chi phí hoạt động. Mặc dù chúng tôi chắc chắn đã thấy giảm đáng kể khối lượng công việc vận hành thông qua tự động hóa mà OpenStack cung cấp, rất khó để định lượng chính xác các mức giảm đó để chứng minh đầu tư hoạt động cần thiết để chạy một nền tảng đám mây hiệu quả. Các tổ chức hoàn toàn tập trung vào việc cắt giảm chi phí thông qua tự động hóa trước tiên nên xem xét tự động hóa các môi trường ảo hiện có thay vì triển khai các môi trường mới.
Chúng tôi cũng đã thấy rất nhiều dự án có mục tiêu được định lượng kém. OpenStack là một kẻ gây ra các trường hợp sử dụng và không phải là thuốc chữa bách bệnh CNTT. Nếu các trường hợp sử dụng không được thỏa thuận trước khi đầu tư vào nền tảng bắt đầu, việc chứng minh đầu tư cuối cùng sẽ rất khó khăn. Đây là lý do tại sao vai trò của Kiến trúc sư rất quan trọng trong việc triển khai OpenStack. Đây là công việc của họ để đảm bảo rằng các yêu cầu cụ thể được viết trước để tất cả các bên liên quan có thể định lượng được sự thành công của nền tảng khi được triển khai.
Với ý nghĩ này, chúng ta hãy xem xét một số trường hợp sử dụng điển hình cho việc triển khai OpenStack.
Public hosting
Như chúng tôi đã đề cập trước đó, OpenStack ban đầu được tạo ra với sự đóng góp mã từ NASA và Rackspace. Sự quan tâm của NASA đối với OpenStack nảy sinh từ mong muốn tạo ra một đám mây điện toán đàn hồi riêng, trong khi mục tiêu chính của Rackspace là tạo ra một nền tảng nguồn mở có thể thay thế cơ sở hạ tầng lưu trữ chia sẻ công khai của họ. Kể từ tháng 4 năm 2015, dịch vụ Đám mây Công cộng Rackspace đã được chuyển sang OpenStack và đã vượt qua chứng nhận Nền tảng Hỗ trợ OpenStack.
Việc triển khai Rackspace cung cấp cả dịch vụ Compute và Object Storage, nhưng một số triển khai có thể chọn chỉ cung cấp Compute hoặc Object Storage và nhận các chứng nhận cho các dịch vụ đó. Chẳng hạn, Dreamhost, một nhà cung cấp đám mây dựa trên OpenStack công khai khác, đã chọn chia nhỏ các dịch vụ được quản lý của họ thành DreamCompute và DreamObjects, triển khai các dịch vụ riêng biệt. Dịch vụ DreamObjects đã được triển khai và cung cấp trước tiên như một lời khen cho dịch vụ lưu trữ web chia sẻ hiện tại của Dreamhost và dịch vụ DreamCompute được giới thiệu sau.
Hầu hết các nhà cung cấp dịch vụ lưu trữ công cộng tập trung chủ yếu vào dịch vụ Điện toán và nhiều người chưa cung cấp kết nối mạng được xác định bằng phần mềm thông qua dịch vụ mạng Neutron (DreamCompute là một ngoại lệ đáng chú ý). Các kiến trúc sư của nền tảng lưu trữ sẽ tập trung đầu tiên vào các vấn đề thuê nhà, thứ hai về các vấn đề bồi hoàn và cuối cùng là về quy mô.
Điện toán hiệu năng cao
Việc triển khai sản xuất đầu tiên của OpenStack bên ngoài NASA và Rackspace là tại một tổ chức phi lợi nhuận của Canada có tên Cybera. Cybera đã triển khai OpenStack như một nền tảng công nghệ vào năm 2011 cho chương trình DAIR của mình, nơi cung cấp tính toán và lưu trữ miễn phí cho các nhà nghiên cứu, doanh nhân và doanh nghiệp nhỏ của Canada.
Các kiến trúc sư tại Cybera, NASA và CERN đều nhận xét về cách dịch vụ của họ có nhiều mối quan tâm giống như trong không gian lưu trữ công cộng. Họ cung cấp tài nguyên tính toán và lưu trữ cho các nhà nghiên cứu và không có nhiều hiểu biết về cách những tài nguyên đó sẽ thực sự được sử dụng. Do đó, mối quan tâm về đa nhiệm an toàn sẽ áp dụng cho các môi trường này cũng giống như chúng làm trong không gian lưu trữ.
Tuy nhiên, các đám mây HPC sẽ tập trung vào hiệu suất. Mặc dù các nhà cung cấp dịch vụ lưu trữ sẽ tìm cách tiết kiệm phần cứng hàng hóa, các đám mây nghiên cứu sẽ tìm cách tối đa hóa hiệu suất bằng cách định cấu hình phần cứng tính toán, lưu trữ và mạng của họ để hỗ trợ các hoạt động thông lượng và khối lượng lớn. Trong đó hầu hết các đám mây sẽ hoạt động tốt nhất bằng cách phát triển phần cứng từ thấp đến trung bình theo chiều ngang với phần cứng hàng hóa, các đám mây hiệu suất cao có xu hướng rất cụ thể về cấu hình hiệu suất của lựa chọn phần cứng của chúng. Cybera đã công bố điểm chuẩn hiệu suất, so sánh nền tảng DAIR của nó với EC2. Kiến trúc sư của các đám mây nghiên cứu cũng có thể tìm cách sử dụng các khả năng thông qua phần cứng hoặc mức độ thấp khác
Phát triển ứng dụng nhanh chóng
Trong vài năm qua, một trường hợp sử dụng đáng kể thứ ba đã xuất hiện cho các môi trường phát triển ứng dụng doanh nghiệp OpenStack. Trong khi lưu trữ công cộng và triển khai tính toán hiệu năng cao có thể có các vùng lớn với hàng trăm nút tính toán và hàng nghìn lõi, thì các triển khai doanh nghiệp có xu hướng có các vùng từ 20 đến 50 nút tính toán. Người áp dụng doanh nghiệp có mối quan tâm mạnh mẽ đến mạng được xác định bằng phần mềm.
Trình điều khiển chính cho việc áp dụng doanh nghiệp của OpenStack là việc sử dụng tích hợp liên tục và phân phối liên tục trong quy trình phát triển ứng dụng ngày càng tăng. Luồng công việc tích hợp liên tục và phân phối liên tục (CI / CD) điển hình sẽ triển khai một ứng dụng hoàn chỉnh trên mỗi cam kết của nhà phát triển, vượt qua các bài kiểm tra đơn vị cơ bản để thực hiện kiểm tra tích hợp tự động. Các triển khai ứng dụng này tồn tại miễn là phải chạy các bài kiểm tra đơn vị, và sau đó một quy trình tự động xé bỏ việc triển khai một khi các bài kiểm tra vượt qua hoặc thất bại. Quy trình công việc này dễ dàng được tạo điều kiện với sự kết hợp của các dịch vụ mạng và tính toán OpenStack.
Trong khi các Kiến trúc sư lưu trữ hoặc điện toán đám mây hiệu năng cao (HPC) dành nhiều thời gian tập trung vào vấn đề thuê nhà và nhân rộng, Kiến trúc sư triển khai doanh nghiệp sẽ dành nhiều thời gian tập trung vào cách tích hợp tính toán OpenStack vào cơ sở hạ tầng hiện có của họ. Việc triển khai doanh nghiệp sẽ thường xuyên tận dụng các triển khai danh mục dịch vụ hiện có và các giải pháp quản lý danh tính. Nhiều triển khai doanh nghiệp cũng sẽ cần tích hợp với các hệ thống theo dõi tài sản và IPAM hiện có.
Ảo hóa chức năng mạng
Một trong những lĩnh vực lớn nhất để phát triển và triển khai nền tảng OpenStack là trong ngành viễn thông. Ảo hóa chức năng mạng (NFV) cung cấp nền tảng IaaS chung cho ngành công nghiệp đó, đang trong quá trình thay thế các thiết bị phần cứng được xây dựng có mục đích cung cấp dịch vụ mạng bằng các thiết bị ảo hóa chạy trên phần cứng hàng hóa. Một số dịch vụ này là định tuyến, proxy, lọc nội dung, cũng như các dịch vụ lõi gói và chuyển mạch khối lượng lớn. Hầu hết các thiết bị này có yêu cầu tính toán mạnh mẽ, và chúng phần lớn không trạng thái. Các khối lượng công việc này rất phù hợp cho mô hình tính toán OpenStack.
Các trường hợp sử dụng NFV thường tận dụng các tính năng phần cứng, có thể gắn trực tiếp các thể hiện tính toán vào các giao diện mạng vật lý trên các nút tính toán. Các thực thể cũng rất nhạy cảm với CPU và cấu trúc liên kết bộ nhớ (NUMA) và các lõi ảo có xu hướng được ánh xạ trực tiếp vào các lõi vật lý. Phối hợp thông qua Heat hoặc TOSCA cũng là một trọng tâm lớn cho các triển khai này.
Các kiến trúc sư của các giải pháp NFV sẽ tập trung chủ yếu vào các vấn đề về vị trí và hiệu suất ảo và ít hơn là các vấn đề thuê nhà và tích hợp.
Soạn thảo một kế hoạch triển khai ban đầu
OpenStack được thiết kế để được sử dụng ở quy mô. Nhiều dự án CNTT có thể bao gồm một vài tài sản vật lý được triển khai trong mạng hiện có, lưu trữ và tính toán cảnh quan, nhưng theo triển khai OpenStack, theo định nghĩa, mạng mới, lưu trữ và tính toán cảnh quan. Bất kỳ dự án nào có quy mô và phạm vi này đều cần có sự phối hợp đáng kể giữa các nhóm khác nhau trong một tổ chức CNTT. Kiểu phối hợp này đòi hỏi lập kế hoạch cẩn thận và, theo kinh nghiệm của chúng tôi, rất nhiều tài liệu.
Vai trò của Kiến trúc sư
Bài viết này được viết để cung cấp các thực tiễn tốt nhất cho vai trò tương đối mới trong nhiều tổ chức, Kiến trúc sư đám mây. Chức năng chính của Cloud Architect là lấy các yêu cầu nghiệp vụ đối với Cơ sở hạ tầng hoặc Nền tảng làm Dịch vụ và thiết kế Cơ sở hạ tầng hoặc Nền tảng làm giải pháp Dịch vụ, đáp ứng các yêu cầu đó. Điều này đòi hỏi kiến thức chuyên sâu về khả năng của phần mềm cơ sở hạ tầng kết hợp với năng lực trong kiến trúc mạng và lưu trữ.
Kiến trúc sư đám mây điển hình sẽ có một nền tảng tính toán và sẽ dựa nhiều vào Kiến trúc sư mạng và lưu trữ trong một tổ chức để hoàn thiện kiến thức kỹ thuật của họ. Vì OpenStack dựa trên hệ điều hành Linux, hầu hết các Kiến trúc sư OpenStack sẽ có kiến thức sâu rộng về nền tảng đó. Nhưng như chúng tôi đã đề cập trước đó, OpenStack thường được phân phối dưới dạng API và Kiến trúc sư OpenStack cũng cần phải thành thạo trong việc phát triển ứng dụng.
OpenStack Architects chịu trách nhiệm trước hết là duy trì một bộ tài liệu thiết kế và triển khai. Thật khó để mô tả một đại dương nếu bạn chưa bao giờ nhìn thấy một đại dương, vì vậy cuốn sách này sẽ hướng dẫn bạn thực hiện các tài liệu mà bạn sẽ tạo khi bạn tạo nó.
Tài liệu thiết kế
Tài liệu đầu tiên mà chúng tôi sẽ tạo ra là tài liệu thiết kế. Điều này có thể được đặt tên là một cái gì đó khác nhau trong tổ chức của bạn, nhưng mục tiêu của tài liệu thiết kế là để giải thích lý do đằng sau tất cả các lựa chọn được thực hiện trong việc triển khai nền tảng. Định dạng có thể thay đổi theo từng nhóm, nhưng chúng tôi muốn nắm bắt các điểm sau:
• Bối cảnh: Đây là lịch sử đằng sau quyết định bắt đầu dự án. Nếu tài liệu sẽ chỉ được tiêu thụ nội bộ, điều này có thể khá ngắn. Nếu nó sẽ được tiêu thụ ra bên ngoài, đây là cơ hội để cung cấp bối cảnh tổ chức cho các nhà cung cấp và đối tác của bạn.
• Tóm tắt: Đây thực sự chỉ là một bản tóm tắt chi tiết của toàn bộ tài liệu. Thông thường, phần này của phân phối sẽ được sử dụng bởi các nhà quản lý, công nghệ và lãnh đạo doanh nghiệp để hiểu tác động kinh doanh của khuyến nghị chung. Yêu cầu và kiến trúc kết quả nên được tóm tắt.
• Yêu cầu: Đây là phần thịt của tài liệu. Yêu cầu có thể ở bất kỳ định dạng nào được chấp nhận cho nhóm quản lý dự án của bạn. Chúng tôi thích định dạng câu chuyện của người dùng và sẽ sử dụng nó trong các ví dụ trong cuốn sách này.
• Kiến trúc vật lý: Đây là giải thích về vai trò và máy móc vật lý đảm nhận các vai trò đó. Điều này nên bao gồm một sơ đồ mạng.
• Kiến trúc dịch vụ: Đây là bản tóm tắt các dịch vụ khả dụng và các mối quan hệ của chúng. Phần này nên bao gồm một sơ đồ dịch vụ.
• Kiến trúc đối tượng thuê: Phải bao gồm một phần mô tả cảnh quan dự kiến bên trong đám mây. Điều này bao gồm những thứ như hương vị tính toán có sẵn, hình ảnh, kiến trúc quản lý danh tính và IPAM hoặc DDI.
• Lộ trình: Phần này là tùy chọn và thường nằm trong một tài liệu khác. Đó là một cơ hội để xác định các khu vực để cải thiện trong các phiên bản tương lai của nền tảng.
Tài liệu thiết kế thường trải qua một số sửa đổi khi dự án được phát triển. Một bước quan trọng ở cuối mỗi lần lặp của nền tảng là điều hòa mọi thay đổi được thực hiện đối với nền tảng với tài liệu thiết kế.
Cẩn thận với phạm vi creep trong tài liệu thiết kế. Cổ vật này có xu hướng biến thành tài liệu về cách thức hoạt động của OpenStack. Hãy nhớ tập trung vào giải thích các quyết định bạn đưa ra thay vì tất cả các tùy chọn có sẵn tại thời điểm đó là gì.
Kế hoạch triển khai
Mọi triển khai OpenStack nên bắt đầu bằng một kế hoạch triển khai. Tài liệu thiết kế mô tả những gì đang được triển khai và tại sao, trong khi kế hoạch triển khai mô tả cách thức. Giống như tài liệu thiết kế, nội dung của một kế hoạch triển khai khác nhau tùy theo từng tổ chức. Nó ít nhất nên bao gồm những điều sau đây:
• Phần cứng: Đây là danh sách các phần cứng tính toán, lưu trữ và mạng có sẵn để triển khai.
• Địa chỉ mạng: Đây là bảng địa chỉ IP và MAC cho các tài sản mạng khi triển khai. Đối với việc triển khai hàng trăm nút tính toán, điều này có lẽ nên được giới hạn ở một tập hợp các Vlan và mạng con có sẵn để triển khai.
• Cấu hình dành riêng cho triển khai: Chúng tôi sẽ cho rằng cấu hình triển khai OpenStack là tự động. Đây là bất kỳ cài đặt nào mà kỹ sư sẽ cần điều chỉnh trước khi khởi chạy dep tự động
