Khi làm việc trong lĩnh vực CNTT, bạn bắt đầu nhận thấy rằng các hệ thống có đặc điểm riêng. Họ có thể linh hoạt, im lặng, lập dị và nghiêm khắc. Họ có thể thu hút hoặc đẩy lùi. Bằng cách này hay cách khác, bạn phải “thương lượng” với họ, điều động giữa các “cạm bẫy” và xây dựng chuỗi tương tác của họ.
Vì vậy, chúng tôi đã có vinh dự được xây dựng một nền tảng đám mây và để làm được điều này, chúng tôi cần phải “thuyết phục” một số hệ thống con hợp tác với chúng tôi. May mắn thay, chúng tôi có “ngôn ngữ API”, trực tiếp và rất nhiều tâm huyết.
Bài viết này sẽ không quá khắt khe về mặt kỹ thuật nhưng sẽ mô tả các vấn đề chúng tôi gặp phải khi xây dựng đám mây. Tôi quyết định mô tả con đường của chúng tôi dưới dạng một tưởng tượng kỹ thuật nhẹ nhàng về cách chúng tôi tìm kiếm một ngôn ngữ chung với các hệ thống và những gì phát sinh từ nó.
Chào mừng đến với con mèo.
Bắt đầu một cuộc hành trình
Cách đây một thời gian, nhóm của chúng tôi được giao nhiệm vụ ra mắt nền tảng đám mây cho khách hàng của mình. Chúng tôi có sự hỗ trợ về mặt quản lý, nguồn lực, phần cứng và quyền tự do lựa chọn công nghệ để triển khai phần mềm của dịch vụ.
Ngoài ra còn có một số yêu cầu:
- dịch vụ cần có tài khoản cá nhân thuận tiện;
- nền tảng phải được tích hợp vào hệ thống thanh toán hiện có;
- phần mềm và phần cứng: OpenStack + Vonfram Fabric (Open Contrail), mà các kỹ sư của chúng tôi đã học cách “nấu” khá giỏi.
Chúng tôi sẽ kể cho bạn vào lúc khác về cách tập hợp nhóm, phát triển giao diện tài khoản cá nhân và đưa ra các quyết định thiết kế nếu cộng đồng Habra quan tâm.
Các công cụ chúng tôi quyết định sử dụng:
- Python + Flask + Swagger + SQLAlchemy - một bộ Python hoàn toàn tiêu chuẩn;
- Vue.js cho giao diện người dùng;
- Chúng tôi quyết định thực hiện tương tác giữa các thành phần và dịch vụ bằng Celery qua AMQP.
Dự đoán các câu hỏi về việc chọn Python, tôi sẽ giải thích. Ngôn ngữ này đã tìm thấy vị trí thích hợp trong công ty của chúng tôi và một nền văn hóa nhỏ nhưng vẫn phát triển xung quanh nó. Vì vậy, người ta quyết định bắt đầu xây dựng dịch vụ trên đó. Hơn nữa, tốc độ phát triển trong những vấn đề như vậy thường có tính chất quyết định.
Vì vậy, hãy bắt đầu làm quen của chúng ta.
Hóa đơn im lặng - thanh toán
Chúng tôi đã biết anh chàng này từ lâu. Anh ấy luôn ngồi cạnh tôi và thầm đếm điều gì đó. Đôi khi anh ấy chuyển tiếp yêu cầu của người dùng cho chúng tôi, xuất hóa đơn cho khách hàng và quản lý các dịch vụ. Một anh chàng chăm chỉ bình thường. Đúng là có những khó khăn. Anh ấy im lặng, đôi khi trầm ngâm và thường có suy nghĩ riêng.
Thanh toán là hệ thống đầu tiên chúng tôi cố gắng kết bạn. Và khó khăn đầu tiên chúng tôi gặp phải đó là khi xử lý dịch vụ.
Ví dụ: khi được tạo hoặc xóa, một tác vụ sẽ được đưa vào hàng đợi thanh toán nội bộ. Do đó, một hệ thống làm việc không đồng bộ với các dịch vụ được triển khai. Để xử lý các loại dịch vụ của mình, chúng tôi cần “đưa” nhiệm vụ của mình vào hàng đợi này. Và ở đây chúng tôi gặp phải một vấn đề: thiếu tài liệu.
Đánh giá theo mô tả của API phần mềm, vẫn có thể giải quyết vấn đề này, nhưng chúng tôi không có thời gian để thực hiện kỹ thuật đảo ngược, vì vậy chúng tôi đã đưa logic ra bên ngoài và tổ chức một hàng đợi nhiệm vụ trên RabbitMQ. Một hoạt động trên một dịch vụ được khách hàng bắt đầu từ tài khoản cá nhân của mình, biến thành “nhiệm vụ” Celery ở phần phụ trợ và được thực hiện ở phía thanh toán và OpenStack. Cần tây giúp việc quản lý công việc, sắp xếp các lần lặp lại và theo dõi trạng thái khá thuận tiện. Bạn có thể đọc thêm về “cần tây”, ví dụ: .
Ngoài ra, việc thanh toán không ngăn được một dự án cạn tiền. Trao đổi với các nhà phát triển, chúng tôi phát hiện ra rằng khi tính toán số liệu thống kê (và chúng tôi cần triển khai chính xác loại logic này), có một mối liên hệ phức tạp giữa các quy tắc dừng. Nhưng những mô hình này không phù hợp lắm với thực tế của chúng ta. Chúng tôi cũng đã triển khai nó thông qua các tác vụ trên Celery, đưa logic quản lý dịch vụ sang phía phụ trợ.
Cả hai vấn đề trên đều dẫn đến việc mã trở nên hơi cồng kềnh và trong tương lai chúng ta sẽ phải cấu trúc lại để chuyển logic làm việc với các tác vụ sang một dịch vụ riêng biệt. Chúng tôi cũng cần lưu trữ một số thông tin về người dùng và dịch vụ của họ trong bảng của mình để hỗ trợ logic này.
Một vấn đề khác là sự im lặng.
Billy im lặng trả lời “Ok” đối với một số yêu cầu API. Ví dụ: đây là trường hợp khi chúng tôi thực hiện thanh toán các khoản thanh toán đã hứa trong quá trình thử nghiệm (sẽ nói thêm về điều đó sau). Các yêu cầu đã được thực hiện chính xác và chúng tôi không thấy bất kỳ lỗi nào.
Tôi đã phải nghiên cứu nhật ký trong khi làm việc với hệ thống thông qua giao diện người dùng. Hóa ra, chính việc thanh toán thực hiện các yêu cầu tương tự, thay đổi phạm vi thành một người dùng cụ thể, chẳng hạn như quản trị viên, chuyển nó vào tham số su.
Nhìn chung, bất chấp những lỗ hổng trong tài liệu và các lỗi API nhỏ, mọi thứ đều diễn ra khá tốt. Nhật ký có thể được đọc ngay cả khi tải nặng nếu bạn hiểu chúng được cấu trúc như thế nào và những gì cần tìm. Cấu trúc của cơ sở dữ liệu được trang trí công phu nhưng khá logic và thậm chí còn hấp dẫn ở một khía cạnh nào đó.
Vì vậy, tóm lại, các vấn đề chính mà chúng tôi gặp phải ở giai đoạn tương tác có liên quan đến các tính năng triển khai của một hệ thống cụ thể:
- những “đặc điểm” không có giấy tờ đã ảnh hưởng đến chúng tôi theo cách này hay cách khác;
- nguồn đóng (thanh toán được viết bằng C++), do đó, không thể giải quyết vấn đề 1 bằng bất kỳ cách nào khác ngoài “thử và sai”.
May mắn thay, sản phẩm có API khá rộng rãi và chúng tôi đã tích hợp các hệ thống con sau vào tài khoản cá nhân của mình:
- mô-đun hỗ trợ kỹ thuật - các yêu cầu từ tài khoản cá nhân của bạn được “ủy quyền” để thanh toán một cách minh bạch cho khách hàng sử dụng dịch vụ;
- mô-đun tài chính - cho phép bạn xuất hóa đơn cho khách hàng hiện tại, xóa nợ và tạo chứng từ thanh toán;
- mô-đun điều khiển dịch vụ - để làm được điều này, chúng tôi phải triển khai trình xử lý của riêng mình. Khả năng mở rộng của hệ thống nằm trong tầm tay của chúng tôi và chúng tôi đã “dạy” Billy một loại dịch vụ mới.
Đó là một chút rắc rối, nhưng bằng cách này hay cách khác, tôi nghĩ Billy và tôi sẽ hợp nhau.
Đi bộ qua cánh đồng vonfram – Vonfram Fabric
Các trường vonfram rải rác với hàng trăm sợi dây, truyền hàng nghìn bit thông tin qua chúng. Thông tin được thu thập thành các “gói”, được phân tích cú pháp, xây dựng các tuyến đường phức tạp, như thể có phép thuật.
Đây là miền của hệ thống thứ hai mà chúng tôi phải kết bạn - Vonfram Fabric (TF), trước đây là OpenContrail. Nhiệm vụ của nó là quản lý thiết bị mạng, cung cấp phần mềm trừu tượng cho chúng ta với tư cách là người dùng. TF - SDN, gói gọn logic phức tạp khi làm việc với thiết bị mạng. Có một bài viết hay về chính công nghệ này, ví dụ: .
Hệ thống được tích hợp với OpenStack (được thảo luận bên dưới) thông qua plugin Neutron.
Tương tác của các dịch vụ OpenStack.
Những người ở bộ phận vận hành đã giới thiệu cho chúng tôi hệ thống này. Chúng tôi sử dụng API của hệ thống để quản lý mạng lưới các dịch vụ của mình. Nó vẫn chưa gây ra cho chúng tôi bất kỳ vấn đề nghiêm trọng hoặc bất tiện nào (tôi không thể nói thay cho những người từ OE), nhưng đã có một số điều kỳ lạ trong tương tác.
Lệnh đầu tiên trông như thế này: các lệnh yêu cầu xuất một lượng lớn dữ liệu tới bảng điều khiển phiên bản khi kết nối qua SSH chỉ cần "gác máy" kết nối, trong khi thông qua VNC thì mọi thứ đều hoạt động chính xác.
Đối với những người chưa quen với vấn đề này, nó có vẻ khá buồn cười: ls /root hoạt động chính xác, trong khi chẳng hạn như top "đóng băng" hoàn toàn. May mắn thay, chúng tôi đã gặp phải vấn đề tương tự trước đây. Nó được quyết định bằng cách điều chỉnh MTU trên tuyến từ các nút điện toán đến bộ định tuyến. Nhân tiện, đây không phải là vấn đề TF.
Vấn đề tiếp theo sắp xảy ra. Trong một khoảnh khắc “đẹp đẽ”, sự kỳ diệu của việc định tuyến đã biến mất, cứ như vậy. TF đã ngừng quản lý định tuyến trên thiết bị.
Chúng tôi đã làm việc với Openstack từ cấp quản trị viên và sau đó chuyển sang cấp độ người dùng được yêu cầu. SDN dường như "chiếm đoạt" phạm vi của người dùng thực hiện các hành động. Thực tế là cùng một tài khoản quản trị viên được sử dụng để kết nối TF và OpenStack. Ở bước chuyển sang người dùng, “ma thuật” biến mất. Người ta quyết định tạo một tài khoản riêng để làm việc với hệ thống. Điều này cho phép chúng tôi làm việc mà không phá vỡ chức năng tích hợp.
Các dạng sống Silicon - OpenStack
Một sinh vật silicon có hình dạng kỳ lạ sống gần cánh đồng vonfram. Trên hết, nó trông giống như một đứa trẻ quá lớn có thể đè bẹp chúng tôi chỉ bằng một cú vung, nhưng không có sự hung hăng rõ ràng nào từ nó. Nó không gây ra sự sợ hãi, nhưng kích thước của nó gây ra sự sợ hãi. Cũng như sự phức tạp của những gì đang xảy ra xung quanh.
OpenStack là cốt lõi của nền tảng của chúng tôi.
OpenStack có một số hệ thống con, trong đó chúng tôi hiện đang sử dụng Nova, Glance và Cinder một cách tích cực nhất. Mỗi người trong số họ có API riêng. Nova chịu trách nhiệm tính toán tài nguyên và tạo phiên bản, Cinder chịu trách nhiệm quản lý khối lượng và ảnh chụp nhanh của chúng, Glance là dịch vụ hình ảnh quản lý các mẫu hệ điều hành và siêu thông tin trên chúng.
Mỗi dịch vụ chạy trong một thùng chứa và nhà môi giới tin nhắn là “thỏ trắng” - RabbitMQ.
Hệ thống này đã mang đến cho chúng tôi những rắc rối không mong đợi nhất.
Và vấn đề đầu tiên xảy ra không lâu sau khi chúng tôi cố gắng kết nối một ổ đĩa bổ sung với máy chủ. API Cinder thẳng thừng từ chối thực hiện nhiệm vụ này. Chính xác hơn, nếu bạn tin vào chính OpenStack, kết nối sẽ được thiết lập nhưng không có thiết bị đĩa nào bên trong máy chủ ảo.
Chúng tôi quyết định đi đường vòng và yêu cầu hành động tương tự từ Nova API. Kết quả là thiết bị kết nối chính xác và có thể truy cập được trong máy chủ. Có vẻ như sự cố xảy ra khi bộ lưu trữ khối không phản hồi với Cinder.
Một khó khăn khác đang chờ đợi chúng tôi khi làm việc với đĩa. Không thể ngắt kết nối âm lượng hệ thống khỏi máy chủ.
Một lần nữa, chính OpenStack “thề” rằng nó đã phá hủy kết nối và giờ đây bạn có thể làm việc chính xác với âm lượng riêng biệt. Nhưng API rõ ràng không muốn thực hiện các thao tác trên đĩa.
Ở đây, chúng tôi quyết định không đấu tranh cụ thể mà thay đổi quan điểm của mình về logic của dịch vụ. Nếu có một instance thì cũng phải có một khối hệ thống. Do đó, người dùng chưa thể xóa hoặc vô hiệu hóa “đĩa” hệ thống mà không xóa “máy chủ”.
OpenStack là một tập hợp hệ thống khá phức tạp với logic tương tác và API trang trí công phu. Chúng tôi được trợ giúp bởi tài liệu khá chi tiết và tất nhiên là cả quá trình thử và sai (chúng tôi sẽ ở đâu nếu không có nó).
Chạy thử nghiệm
Chúng tôi đã tiến hành phóng thử vào tháng XNUMX năm ngoái. Nhiệm vụ chính là thử nghiệm dự án của chúng tôi ở chế độ chiến đấu từ phía kỹ thuật và phía UX. Khán giả được mời có chọn lọc và cuộc thử nghiệm đã kết thúc. Tuy nhiên, chúng tôi cũng để lại tùy chọn yêu cầu quyền truy cập vào thử nghiệm trên trang web của chúng tôi.
Tất nhiên, bản thân bài kiểm tra không phải là không có những khoảnh khắc hài hước, bởi vì đây là lúc cuộc phiêu lưu của chúng ta mới bắt đầu.
Thứ nhất, chúng tôi đã đánh giá phần nào sự quan tâm đến dự án không chính xác và phải nhanh chóng thêm các nút tính toán ngay trong quá trình thử nghiệm. Một trường hợp phổ biến cho một cụm, nhưng ở đây cũng có một số sắc thái. Tài liệu về phiên bản TF cụ thể cho biết phiên bản cụ thể của kernel hoạt động với vRouter đã được thử nghiệm. Chúng tôi quyết định khởi chạy các nút có hạt nhân mới hơn. Kết quả là TF không nhận được tuyến đường từ các nút. Tôi đã phải khẩn trương cuộn lại hạt nhân.
Một sự tò mò khác liên quan đến chức năng của nút “thay đổi mật khẩu” trong tài khoản cá nhân của bạn.
Chúng tôi quyết định sử dụng JWT để tổ chức quyền truy cập vào tài khoản cá nhân của mình để không phải làm việc với các phiên. Vì các hệ thống rất đa dạng và phân tán rộng rãi nên chúng tôi quản lý mã thông báo của riêng mình, trong đó chúng tôi “gói” các phiên thanh toán và mã thông báo từ OpenStack. Tất nhiên, khi mật khẩu được thay đổi, mã thông báo sẽ “bị hỏng” vì dữ liệu người dùng không còn hợp lệ và cần được phát hành lại.
Chúng tôi đã mất dấu điểm này và đơn giản là không có đủ nguồn lực để nhanh chóng hoàn thành phần này. Chúng tôi đã phải loại bỏ chức năng này ngay trước khi bắt đầu thử nghiệm.
Hiện tại chúng tôi đăng xuất người dùng nếu mật khẩu đã được thay đổi.
Bất chấp những sắc thái này, quá trình thử nghiệm vẫn diễn ra tốt đẹp. Trong vài tuần, có khoảng 300 người ghé qua. Chúng tôi có thể nhìn sản phẩm qua con mắt của người dùng, thử nghiệm sản phẩm trong thực tế và thu thập phản hồi chất lượng cao.
Để được tiếp tục
Đối với nhiều người trong chúng tôi, đây là dự án đầu tiên có quy mô như vậy. Chúng tôi đã học được một số bài học quý giá về cách làm việc theo nhóm và đưa ra các quyết định về kiến trúc và thiết kế. Cách tích hợp các hệ thống phức tạp với ít tài nguyên và đưa chúng vào sản xuất.
Tất nhiên, có một số việc phải làm cả về mã và giao diện tích hợp hệ thống. Dự án còn khá non trẻ nhưng chúng tôi có đầy tham vọng phát triển nó thành một dịch vụ đáng tin cậy và tiện lợi.
Chúng tôi đã có thể thuyết phục các hệ thống. Bill xử lý các yêu cầu đếm, thanh toán và người dùng trong tủ của mình một cách nghiêm túc. Sự “ma thuật” của trường vonfram mang đến cho chúng ta khả năng liên lạc ổn định. Và chỉ OpenStack đôi khi trở nên thất thường, hét lên điều gì đó như “'WSREP chưa chuẩn bị nút để sử dụng ứng dụng. Nhưng đó lại là một câu chuyện hoàn toàn khác...
Gần đây chúng tôi đã ra mắt dịch vụ.
Bạn có thể tìm hiểu tất cả các chi tiết trên của chúng tôi .
Nhóm phát triển CLO
Liên kết hữu ích
OpenStack
Vải vonfram
Nguồn: www.habr.com