Saat Anda bekerja di bidang TI, Anda mulai menyadari bahwa sistem memiliki karakternya sendiri. Mereka bisa menjadi fleksibel, pendiam, eksentrik, dan tegas. Mereka bisa menarik atau menolak. Dengan satu atau lain cara, Anda harus “bernegosiasi” dengan mereka, bermanuver di antara “perangkap” dan membangun rantai interaksi mereka.
Jadi kami mendapat kehormatan untuk membangun platform cloud, dan untuk ini kami perlu “membujuk” beberapa subsistem untuk bekerja sama dengan kami. Untungnya, kami memiliki “bahasa API”, tangan langsung dan banyak antusiasme.
Artikel ini tidak membahas secara teknis, tetapi akan menjelaskan masalah yang kami temui saat membangun cloud. Saya memutuskan untuk menggambarkan jalur kami dalam bentuk fantasi teknis ringan tentang bagaimana kami mencari bahasa yang sama dengan sistem dan apa hasilnya.
Selamat datang di kucing.
Awal perjalanan
Beberapa waktu lalu, tim kami ditugaskan meluncurkan platform cloud untuk klien kami. Kami mendapat dukungan manajemen, sumber daya, tumpukan perangkat keras, dan kebebasan dalam memilih teknologi untuk mengimplementasikan bagian perangkat lunak dari layanan.
Ada juga sejumlah persyaratan:
- layanan ini memerlukan akun pribadi yang nyaman;
- platform harus diintegrasikan ke dalam sistem penagihan yang ada;
- perangkat lunak dan perangkat keras: OpenStack + Tungsten Fabric (Open Contrail), yang telah dipelajari oleh teknisi kami untuk “dimasak” dengan cukup baik.
Kami akan memberi tahu Anda lain kali tentang bagaimana tim dibentuk, antarmuka akun pribadi dikembangkan, dan keputusan desain dibuat, jika komunitas Habra tertarik.
Alat yang kami putuskan untuk digunakan:
- Python + Flask + Swagger + SQLAlchemy - set Python yang sepenuhnya standar;
- Vue.js untuk antarmuka;
- Kami memutuskan untuk melakukan interaksi antara komponen dan layanan menggunakan Celery melalui AMQP.
Mengantisipasi pertanyaan tentang memilih Python, saya akan jelaskan. Bahasa ini telah menemukan tempatnya di perusahaan kami dan budaya kecil namun tetap berkembang telah berkembang di sekitarnya. Oleh karena itu, diputuskan untuk mulai membangun layanan di atasnya. Terlebih lagi, kecepatan perkembangan masalah-masalah seperti ini sering kali menentukan.
Jadi, mari kita mulai perkenalan kita.
Silent Bill - penagihan
Kami sudah lama mengenal orang ini. Dia selalu duduk di sebelahku dan diam-diam menghitung sesuatu. Terkadang dia meneruskan permintaan pengguna kepada kami, menerbitkan faktur klien, dan mengelola layanan. Seorang pria pekerja keras biasa. Benar, ada kesulitan. Dia pendiam, terkadang berpikir dan sering memikirkan dirinya sendiri.
Penagihan adalah sistem pertama yang kami coba berteman. Dan kesulitan pertama yang kami temui adalah saat memproses jasa.
Misalnya, saat dibuat atau dihapus, tugas masuk ke antrean penagihan internal. Dengan demikian, sistem kerja asinkron dengan layanan diterapkan. Untuk memproses jenis layanan kami, kami perlu "memasukkan" tugas kami ke dalam antrean ini. Dan di sini kami menemui masalah: kurangnya dokumentasi.
Dilihat dari deskripsi API perangkat lunak, masalah ini masih dapat diselesaikan, tetapi kami tidak punya waktu untuk melakukan rekayasa balik, jadi kami mengeluarkan logika dan mengatur antrian tugas di atas RabbitMQ. Operasi pada layanan dimulai oleh klien dari akun pribadinya, berubah menjadi “tugas” Seledri di backend dan dilakukan di sisi penagihan dan OpenStack. Seledri membuatnya cukup nyaman untuk mengelola tugas, mengatur pengulangan, dan memantau status. Anda dapat membaca lebih lanjut tentang “seledri”, misalnya, .
Selain itu, penagihan tidak menghentikan proyek yang kehabisan uang. Saat berkomunikasi dengan pengembang, kami menemukan bahwa saat menghitung statistik (dan kami perlu menerapkan logika seperti ini), terdapat keterkaitan yang kompleks antara aturan penghentian. Namun model-model ini tidak sesuai dengan kenyataan yang ada. Kami juga menerapkannya melalui tugas di Celery, membawa logika manajemen layanan ke sisi backend.
Kedua masalah di atas menyebabkan kode menjadi sedikit membengkak dan di masa depan kita harus melakukan refaktorisasi untuk memindahkan logika untuk mengerjakan tugas ke dalam layanan terpisah. Kita juga perlu menyimpan beberapa informasi tentang pengguna dan layanan mereka di tabel kita untuk mendukung logika ini.
Masalah lainnya adalah keheningan.
Billy diam-diam menjawab “Oke” untuk beberapa permintaan API. Hal ini terjadi, misalnya, ketika kami melakukan pembayaran atas pembayaran yang dijanjikan selama ujian (lebih lanjut tentang itu nanti). Permintaan dijalankan dengan benar dan kami tidak melihat kesalahan apa pun.
Saya harus mempelajari log saat bekerja dengan sistem melalui UI. Ternyata penagihan itu sendiri melakukan permintaan serupa, mengubah cakupan ke pengguna tertentu, misalnya admin, meneruskannya ke parameter su.
Secara umum, meskipun ada kesenjangan dalam dokumentasi dan sedikit kelemahan API, semuanya berjalan cukup baik. Log dapat dibaca bahkan di bawah beban berat jika Anda memahami strukturnya dan apa yang harus dicari. Struktur databasenya penuh hiasan, namun cukup logis dan dalam beberapa hal bahkan menarik.
Jadi, untuk meringkas, masalah utama yang kami temui pada tahap interaksi terkait dengan fitur implementasi sistem tertentu:
- “fitur” tidak terdokumentasi yang mempengaruhi kami dalam satu atau lain cara;
- sumber tertutup (penagihan ditulis dalam C++), akibatnya - tidak mungkin menyelesaikan masalah 1 dengan cara apa pun selain “trial and error”.
Untungnya, produk tersebut memiliki API yang cukup luas dan kami telah mengintegrasikan subsistem berikut ke dalam akun pribadi kami:
- modul dukungan teknis - permintaan dari akun pribadi Anda “diproksikan” ke penagihan secara transparan untuk klien layanan;
- modul keuangan - memungkinkan Anda menerbitkan faktur kepada klien saat ini, melakukan penghapusan, dan menghasilkan dokumen pembayaran;
- modul kontrol layanan - untuk ini kami harus mengimplementasikan penangan kami sendiri. Perluasan sistem berperan dalam kendali kami dan kami “mengajarkan” Billy jenis layanan baru.
Agak merepotkan, tapi bagaimanapun caranya, menurutku Billy dan aku akan akur.
Berjalan melalui ladang tungsten – Kain Tungsten
Bidang tungsten dipenuhi ratusan kabel, mengalirkan ribuan bit informasi melaluinya. Informasi dikumpulkan ke dalam “paket”, diurai, membangun rute yang rumit, seolah-olah secara ajaib.
Ini adalah domain dari sistem kedua yang menjadi teman kami - Tungsten Fabric (TF), sebelumnya OpenContrail. Tugasnya adalah mengelola peralatan jaringan, menyediakan abstraksi perangkat lunak kepada kita sebagai pengguna. TF - SDN, merangkum logika kompleks bekerja dengan peralatan jaringan. Ada artikel bagus tentang teknologi itu sendiri, misalnya, .
Sistem ini terintegrasi dengan OpenStack (dibahas di bawah) melalui plugin Neutron.
Interaksi layanan OpenStack.
Orang-orang dari departemen operasi memperkenalkan kami pada sistem ini. Kami menggunakan API sistem untuk mengelola tumpukan jaringan layanan kami. Ini belum menimbulkan masalah atau ketidaknyamanan yang serius bagi kami (saya tidak bisa mewakili orang-orang dari OE), tetapi ada beberapa keanehan dalam interaksinya.
Yang pertama terlihat seperti ini: perintah yang memerlukan keluaran data dalam jumlah besar ke konsol instance saat menghubungkan melalui SSH hanya “menutup” koneksi, sementara melalui VNC semuanya bekerja dengan benar.
Bagi yang belum familiar dengan masalahnya, tampilannya cukup lucu: ls /root berfungsi dengan benar, sedangkan, misalnya, top "membeku" sepenuhnya. Untungnya, kami pernah mengalami masalah serupa sebelumnya. Hal ini diputuskan dengan menyetel MTU pada rute dari node komputasi ke router. Ngomong-ngomong, ini bukan masalah TF.
Masalah berikutnya sudah dekat. Dalam satu momen yang “indah”, keajaiban routing menghilang begitu saja. TF telah berhenti mengelola perutean pada peralatan.
Kami bekerja dengan Openstack dari level admin dan setelah itu berpindah ke level pengguna yang diperlukan. SDN tampaknya “membajak” cakupan pengguna yang melakukan tindakan tersebut. Faktanya adalah akun admin yang sama digunakan untuk menghubungkan TF dan OpenStack. Pada langkah beralih ke pengguna, “keajaiban” menghilang. Diputuskan untuk membuat akun terpisah untuk bekerja dengan sistem. Hal ini memungkinkan kami bekerja tanpa merusak fungsi integrasi.
Bentuk Kehidupan Silikon - OpenStack
Makhluk silikon berbentuk aneh tinggal di dekat ladang tungsten. Yang terpenting, ia terlihat seperti anak kecil yang bisa menghancurkan kita dengan satu ayunan, tapi tidak ada agresi yang jelas datang darinya. Itu tidak menimbulkan rasa takut, tetapi ukurannya menimbulkan rasa takut. Begitu pula dengan kompleksitas yang terjadi di sekitar.
OpenStack adalah inti dari platform kami.
OpenStack memiliki beberapa subsistem, yang saat ini kami paling aktif menggunakan Nova, Glance, dan Cinder. Masing-masing memiliki API sendiri. Nova bertanggung jawab atas sumber daya komputasi dan pembuatan instance, Cinder bertanggung jawab untuk mengelola volume dan snapshotnya, Glance adalah layanan gambar yang mengelola templat OS dan metainformasi di dalamnya.
Setiap layanan berjalan dalam sebuah container, dan perantara pesannya adalah “kelinci putih” - RabbitMQ.
Sistem ini memberi kami masalah yang paling tidak terduga.
Dan masalah pertama tidak lama kemudian terjadi ketika kami mencoba menghubungkan volume tambahan ke server. Cinder API dengan tegas menolak untuk melakukan tugas ini. Lebih tepatnya, menurut OpenStack sendiri, koneksi dibuat, tetapi tidak ada perangkat disk di dalam server virtual.
Kami memutuskan untuk mengambil jalan memutar dan meminta tindakan yang sama dari Nova API. Hasilnya adalah perangkat terhubung dengan benar dan dapat diakses di dalam server. Tampaknya masalah terjadi ketika penyimpanan blok tidak merespons Cinder.
Kesulitan lain menanti kami saat bekerja dengan disk. Volume sistem tidak dapat diputuskan sambungannya dari server.
Sekali lagi, OpenStack sendiri "bersumpah" bahwa ia telah merusak koneksi dan sekarang Anda dapat bekerja dengan volume secara terpisah dengan benar. Namun API dengan tegas tidak ingin melakukan operasi pada disk.
Di sini kami memutuskan untuk tidak bertengkar secara khusus, tetapi mengubah pandangan kami tentang logika layanan. Kalau ada instance, pasti ada volume sistemnya juga. Oleh karena itu, pengguna belum dapat menghapus atau menonaktifkan “disk” sistem tanpa menghapus “server”.
OpenStack adalah seperangkat sistem yang agak rumit dengan logika interaksinya sendiri dan API yang penuh hiasan. Kami terbantu dengan dokumentasi yang cukup rinci dan, tentu saja, trial and error (di mana kami tanpanya).
Uji coba
Kami melakukan uji peluncuran pada bulan Desember tahun lalu. Tugas utamanya adalah menguji proyek kami dalam mode pertempuran dari sisi teknis dan dari sisi UX. Penonton diundang secara selektif dan pengujian ditutup. Namun, kami juga meninggalkan opsi untuk meminta akses pengujian di situs web kami.
Ujiannya sendiri tentu saja bukannya tanpa momen-momen lucu, karena disinilah petualangan kita baru dimulai.
Pertama, kami salah menilai minat terhadap proyek dan harus segera menambahkan node komputasi tepat selama pengujian. Kasus umum untuk sebuah cluster, tetapi ada beberapa perbedaan di sini juga. Dokumentasi untuk versi TF tertentu menunjukkan versi spesifik kernel yang digunakan untuk menguji vRouter. Kami memutuskan untuk meluncurkan node dengan kernel yang lebih baru. Akibatnya, TF tidak menerima rute dari node. Saya harus segera memutar kembali kernelnya.
Keingintahuan lainnya terkait dengan fungsi tombol “ubah kata sandi” di akun pribadi Anda.
Kami memutuskan untuk menggunakan JWT untuk mengatur akses ke akun pribadi kami agar tidak bekerja dengan sesi. Karena sistemnya beragam dan tersebar luas, kami mengelola token kami sendiri, di mana kami “membungkus” sesi dari penagihan dan token dari OpenStack. Ketika kata sandi diubah, token tentu saja “menjadi buruk”, karena data pengguna tidak valid lagi dan perlu diterbitkan ulang.
Kami lupa akan hal ini, dan tidak ada sumber daya yang cukup untuk menyelesaikan bagian ini dengan cepat. Kami harus menghentikan fungsinya sebelum meluncurkan pengujian.
Saat ini kami logout pengguna jika kata sandi telah diubah.
Terlepas dari perbedaan ini, pengujian berjalan dengan baik. Dalam beberapa minggu, sekitar 300 orang mampir. Kami dapat melihat produk dari sudut pandang pengguna, mengujinya dalam tindakan, dan mengumpulkan masukan berkualitas tinggi.
Untuk dilanjutkan
Bagi banyak dari kita, ini adalah proyek pertama sebesar ini. Kami mempelajari sejumlah pelajaran berharga tentang cara bekerja sebagai tim dan membuat keputusan arsitektur dan desain. Bagaimana mengintegrasikan sistem yang kompleks dengan sedikit sumber daya dan memasukkannya ke dalam produksi.
Tentu saja, ada sesuatu yang perlu dikerjakan baik dari segi kode maupun antarmuka integrasi sistem. Proyek ini masih cukup muda, namun kami memiliki ambisi untuk mengembangkannya menjadi layanan yang andal dan nyaman.
Kami sudah mampu meyakinkan sistem. Bill dengan patuh menangani penghitungan, penagihan, dan permintaan pengguna di lemarinya. “Keajaiban” medan tungsten memberi kita komunikasi yang stabil. Dan hanya OpenStack yang terkadang berubah-ubah, meneriakkan sesuatu seperti “'WSREP belum menyiapkan node untuk penggunaan aplikasi.” Tapi itu cerita yang sama sekali berbeda...
Kami baru saja meluncurkan layanan ini.
Anda dapat mengetahui semua detailnya di kami .
tim pengembangan CLO
Berguna Link
OpenStack
Kain Tungsten
Sumber: www.habr.com