OpenStack: seluruh kebenaran tentang rilis "royal"

Woland di M. Bulgakov mengatakan bahwa "batu bata tanpa alasan tidak akan pernah jatuh di kepala siapa pun." Mungkin begitu, tetapi ketika mereka bertanya kepada saya dua setengah tahun yang lalu apakah saya ingin mengenal OpenStack, itu adalah batu bata yang sangat terselubung (dan bahkan bukan batu bata, tetapi lempengan granit pada awalnya). Itu adalah 2016 yang menjadi apa yang disebut "point of no return" bagi saya, meletakkan dasar bagi perkembangan cepat konsep-konsep dunia terbuka dan secara signifikan mempengaruhi mentalitas, mengubah hidup masa depan saya menjadi liburan. "Liburan", yang selalu bersamaku.

2016 - hari ini

OpenStack bukanlah cinta pada pandangan pertama. Rilis pertama yang saya gunakan untuk pengujian adalah Kilo, yang dengan mudah berima dengan kata "sedih." Setelah ada selama tiga minggu, ia diharapkan digantikan oleh Liberty, yang, di bawah pembungkus yang menarik - catatan rilis - tidak dapat memenuhi harapan yang tinggi. Mitaka belum begitu banyak membawa fungsi baru karena mengandung banyak koreksi dan "tambalan", dan masih (!) Berhasil digunakan dalam lingkungan yang produktif. Newton, pada kenyataannya, adalah titik balik dalam sejarah OpenStack, menyediakan begitu banyak arsitektur, logis dan, sebagai akibatnya, perubahan konfigurasi yang selamanya memblokir jalur upgrade dari versi sebelumnya untuk banyak cloud pribadi. Tetapi dengan rilis Ocata pada tahun 2017, menurut analis , bahwa "zaman keemasan" OpenStack dimulai, yang meliputi Pike, Queens dan, saya sangat berharap demikian, Rocky, yang pada awal yang rendah, akan masuk.


Artikel ini akan fokus pada rilis OpenStack stabil terbaru - Queens, pada beberapa inovasi dan kekurangan - dari sudut pandang seseorang yang mengotomatiskan penyebarannya berdasarkan distribusi Ubuntu 16,04 LTS (dan terus melakukannya karena tidak ada batas kesempurnaan) .

Tidak ada begitu banyak materi tentang Queens di jaringan (jika Anda mengecualikan dokumentasi dan laporan resmi dari OpenStack Summit baru-baru ini di Vancouver dari sampel), dan jumlah ulasan dari penyedia cloud dan integrator sistem dapat dihitung dengan jari satu tangan. Tidak mengherankan, pendahulunya - Pike, yang dukungan resminya akan bertahan delapan bulan lagi - dengan ratusan pengguna bekerja dan prosedur peningkatan yang terdokumentasi dengan baik, terlihat lebih cocok untuk implementasi. Tim kami, yang telah mengikuti proses pengembangan Queens sejak awal, melangkah lebih jauh dari banyak dan dengan percaya diri meluncurkan "baru" ke dalam produksi. Jadi seberapa dalam lubang kelinci itu?

(selanjutnya terminologi OpenStack akan digunakan secara luas; diasumsikan bahwa pembaca setidaknya akrab dengan arsitektur tipikal)

Fitur yang Berguna

1. Bagi saya pribadi, bonus yang bagus dalam rilis baru ini adalah perluasan fungsi utilitas nova-manage: sekarang Anda dapat menghapus host dari beberapa sel (Sel v2) dan mentransfernya ke yang lain! Pike harus menulis permintaan basis data yang terpisah, dan sekarang sudah tersedia "di luar kotak".
2. Membuat peran khusus (_member_ secara default) untuk Keystone adalah "cut out" dari tahap bootstrap. Alasan untuk ini adalah transisi final ke API v3, yang memiliki bentuk lain dari mekanisme otorisasi dan otentikasi, yang juga meningkatkan keamanan infrastruktur (setelah semua, ada juga id tetap untuk peran pengguna ...) Namun, ini tidak berarti sama sekali bahwa peran pengguna tidak diperlukan - awal atau Anda harus membuatnya nanti.
   

   Prakiraan: dimulai dengan rilis ini, Identity API v2 telah ditinggalkan; dukungannya kemungkinan akan berhenti total dalam setahun (pesimistis dalam rilis Stein).

3. Neutron l3- dan dhcp-agent mendapatkan kesempatan failover otomatis - pengalihan otomatis (penjadwalan ulang) jaringan dan router dari agen yang dimatikan ke yang aktif. Fungsi DVR DVR diaktifkan secara default ( [DEFAULT]/router_distributed , [DEFAULT]/l3_ha ). DVR / SNAT dialokasikan dalam ruang nama yang terpisah. Saat membuat router, snat dibuat secara default, mengambil alamat IP lain dari subnet internal:
   
   Bundel ini memungkinkan Anda untuk dengan cepat beralih dari arus ke router cadangan agen l3 yang berjalan di node lain jika terjadi kegagalan layanan SNAT.
4. Semua fungsionalitas Neutron vpn-agent ditransfer ke l3-agent; dalam konfigurasi-nya Anda perlu membuat satu-satunya edit:
   
   

    [agent]/extensions = vpnaas 

   
   Akhirnya, kehadiran agen vpn tidak lagi mengganggu konstruksi logika penerapan otomatis dalam kasus dimasukkannya peran (sebelumnya, agen vpn dan l3 saling eksklusif: jika Anda meletakkan satu paket, yang lainnya dihapus).
5. Glance-registry (proksi untuk berinteraksi dengan database di API v1) telah dinyatakan sebagai layanan yang ketinggalan zaman, sekarang Anda dapat mengonfigurasi dan hanya membutuhkan layanan glance-api. Tidak ada kejutan, tetapi mereka akan dibahas sedikit kemudian.
6. Mamma mia! Heat-dashboard dikirimkan dalam paket terpisah (panel plug-in) untuk Horizon. Plugin telah mengalami banyak perubahan, tetapi fungsi yang paling tidak terduga adalah ... drag & drop objek dalam proses menghasilkan template. Lebih mudah dilihat sekali:
   
   
   
7. Dukungan tambahan untuk multi-attach volume dalam Cinder - kemampuan untuk menghubungkan disk tunggal ke beberapa mesin virtual. Sejauh ini, fungsi ini telah diimplementasikan hanya untuk sejumlah driver yang didukung oleh layanan: LVM, NetApp / SolidFire, Dell EMC ScaleIO dan Oracle ZFSSA - pada kenyataannya, ini adalah langkah maju yang sangat besar untuk seluruh proyek (implementasi mekanisme memakan waktu lebih dari dua tahun ).
   

   Prakiraan: untuk dukungan Ceph RBD untuk multi-attach volume Cinder belum diumumkan; kemungkinan besar, itu harus diharapkan tidak lebih awal dari satu tahun (optimis - dalam rilis Stein).

Bug yang mengganggu

(Bug-bug berikut ditemukan ketika menggunakan OpenStack Queens pada distribusi Ubuntu 16.04.4 LTS (Xenial Xerus); ada kemungkinan mereka tidak akan muncul di distribusi Linux lainnya)

1. Dalam komunitas Linux, ada yang namanya “maintainer” - spesialis yang memelihara / memelihara / memimpin komponen perangkat lunak tertentu (dalam kasus tertentu, paket biner). Jadi, pengelola Ubuntu lagi (ada bug dalam rilis Pike) menyediakan paket untuk layanan basis data seri waktu reguler - Gnocchi. Menginstalnya dalam lingkungan Python 2.7 melalui apt “break” beberapa layanan terkait yang berjalan di bawah libapache2-mod-wsgi: Keystone, Cinder, Nova Placement, Horizon. Kasus yang menyedihkan adalah ketika Anda ingin menggunakan satu metode pengiriman paket ke sistem. Namun, sementara untuk Gnocchi mereka setidaknya mencoba untuk mengkompilasi paket, untuk Octavia hanya pip dan git yang masih ada.
2. Saya tidak berpura-pura mengatakan, tetapi mungkin pengelola yang sama memiliki andil dalam menciptakan paket nova-compute. Setidaknya, ini akan menjelaskan mengapa ketika mereka diinstal pada sistem (rakitan kernel 116, 119 dan 124; versi paket dari 17.0.1 hingga 17.0.4) installer "jatuh" dengan kesalahan:
   
   

    Setting up nova-compute-libvirt (2:17.0.1-0ubuntu1~cloud0) ... adduser: The user 'nova' does not exist. dpkg: error processing package nova-compute-libvirt (--configure): subprocess installed post-installation script returned error exit status 1 dpkg: dependency problems prevent configuration of nova-compute-kvm: nova-compute-kvm depends on nova-compute-libvirt (= 2:17.0.1-0ubuntu1~cloud0); however: Package nova-compute-libvirt is not configured yet. 

   
   Begini masalahnya: selama instalasi, skrip dijalankan yang harus membuat grup sistem nova dan pengguna sistem nova. Script gagal dengan kesalahan, instalasi macet, dan solusi ditambahkan ke otomatisasi: lakukan gerakan yang disebutkan sebelum menginstal paket. Ngomong-ngomong, bug ini masih belum ditutup.
   

   UPD: dalam proses penulisan artikel, bug akhirnya dikonfirmasi dan menetapkan prioritas rata-rata. Pada saat menyelesaikan masalah (ketergantungan siklus paket Nova satu sama lain), pengelola mengusulkan solusi lain: pertama instal paket nova-common, kemudian nova-compute. Dalam waktu dekat kita dapat mengharapkan versi paket 17.0.5, tanpa kekurangan ini.

3. Menguji operasi layanan Neutron FWaaS, ternyata ketika firewall dihapus dari router terdistribusi, tidak ada yang terjadi ... benar-benar. Firewall berubah dari status "online" ke status "pending delete" yang abadi, dan Anda dapat memecahkan masalah dengan menggunakan kueri ke basis data atau dengan menghapus seluruh router (bug ini ada pada rilis Pike). Masalah utama saat ini adalah bahwa perbaikan (yang benar-benar menyelesaikan!) Diusulkan beberapa bulan yang lalu, tetapi masih belum sampai ke rilis stabil terakhir.
4. Sudah pada tahap pengujian beban infrastruktur, ditemukan bahwa "neutron-openvswitch-agent MAKAN CPU AAAAAAA" - dalam mode siaga, agen openvswitch memuat salah satu inti prosesor pada 100%:
   
   

    $ ps aux | grep 16233 neutron 16233 99.5 0.0 311112 143156 ? Rs 19:47 67:11 /usr/bin/python2 /usr/bin/neutron-openvswitch-agent --config-file=/etc/neutron/neutron.conf --config-file=/etc/neutron/plugins/ml2/openvswitch_agent.ini --log-file=/var/log/neutron/neutron-openvswitch-agent.log $ time strace -c -p 16233 % time seconds usecs/call calls errors syscall ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 0 95725 epoll_wait 0.00 0.000000 0 15 read 0.00 0.000000 0 6 open 0.00 0.000000 0 6 close 0.00 0.000000 0 6 stat 0.00 0.000000 0 15 fstat 0.00 0.000000 0 20 sendto 0.00 0.000000 0 79 41 recvfrom 0.00 0.000000 0 2 setsockopt 0.00 0.000000 0 94 epoll_ctl ------ ----------- ----------- --------- --------- ---------------- 100.00 0.000362 95968 41 total real 0m10.300s user 0m0.324s sys 0m2.576s 

   
   Solusi untuk masalah tersebut ditemukan oleh pengembang layanan sesegera mungkin; Perbaikan disediakan dalam versi paket Neutron 12.0.1-0ubuntu1.1.

Royal Fakap

Di OpenStack Queens, pengembang telah memperkenalkan metode baru untuk mengunduh gambar - unduhan web, yang memungkinkan pengguna akhir untuk "mengunggah" gambar dengan referensi. Sekali waktu, ketika Gambar API v1 belum ditinggalkan dan tidak diganti oleh API v2, fungsi ini ada. Tampaknya apa yang bisa salah? ..


Dalam konfigurasi layanan glance-api, kedua metode pemuatan gambar - secara langsung dan dengan referensi - diaktifkan secara default ( [DEFAULT]/enabled_import_methods ). Dalam mengejar tujuan sederhana menguji opsi, saya mematikan salah satu metode, membebani layanan, dan bergegas!

 CRITICAL glance [-] Unhandled error: ValueError: tuple.index(x): x not in tuple ERROR glance Traceback (most recent call last): ERROR glance File "/usr/bin/glance-api", line 10, in <module> ERROR glance sys.exit(main()) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 97, in main ERROR glance fail(e) ERROR glance File "/usr/lib/python2.7/dist-packages/glance/cmd/api.py", line 71, in fail ERROR glance return_code = KNOWN_EXCEPTIONS.index(type(e)) + 1 ERROR glance ValueError: tuple.index(x): x not in tuple 

Setelah mengutak-atik tambalan, saya kembali membebani layanan:

 glance-api[26538]: ERROR: Value for option enabled_import_methods is not valid: Value should start with "[" systemd[1]: glance-api.service: Main process exited, code=exited, status=4/NOPERMISSION systemd[1]: glance-api.service: Unit entered failed state. systemd[1]: glance-api.service: Failed with result 'exit-code'. 

Serius, atau apa ?! Opsi dalam konfigurasi telah memperoleh formulir yang tidak memadai berikut:

 [DEFAULT]/enabled_import_methods = [glance-direct] 

Tentu saja, bug dibuka dengan hati-hati oleh saya. Pengembang pada saat memecahkan masalah bahkan memposting pengumuman tentang masalah yang diketahui ini, diketahui oleh mereka dan mengirimkan komitmen ke cabang utama proyek. Dua bulan setelah ditemukannya bug tersebut, perbaikannya "pergi" untuk rilis di masa depan; pemilik Queens yang beruntung harus menunggu paket Glance versi 16.0.2.
Semua baik-baik saja itu berakhir dengan baik.

"Jangan kehilangan kepalamu, ayunkan ototmu"

Selama pekerjaan otomatisasi penyebaran (juga melibatkan konfigurasi dan langkah-langkah pengujian fungsional), Queens terbukti kuat, tidak kelebihan dengan fitur-fitur baru, tanpa "penopang" mencuat dari mana-mana, menetapkan bar tinggi untuk penggantinya.

Namun, terlepas dari kenyataan bahwa Queens adalah rilis OpenStack ketujuh belas (!), Kecenderungan umum telah dipertahankan selama bertahun-tahun: "yang tak terduga tidak dapat diramalkan oleh intuisi yang tak terduga ". Kutipan ini dari jalur Proyek Atlantida, menurut saya, dengan cara terbaik menggambarkan seluruh jajaran sensasi yang diterima dari berinteraksi dengan produk. Di satu sisi, penyebaran layanan reguler (Keystone, Glance, Swift, Cinder, Nova, Neutron, Horizon) dengan pengaturan dasar telah lama di-debug dan tidak akan menimbulkan masalah bahkan untuk insinyur pemula. Di sisi lain, ketika datang untuk memperkenalkan layanan yang relatif muda, "liburan" tersebut dimulai: mengurutkannya seperti yang Anda inginkan dalam dokumentasi yang sedikit, bersiap-siap untuk menghabiskan hari melihat kode dan duduk di pelacak bug populer.

Namun, semua penderitaan ini hanyalah efek samping dari sindrom Stockholm. Tapi nyatanya, latihan open-stack menggetarkan otak lebih cepat daripada game logis apa pun, mengembangkan keterampilan yang berguna secara eksponensial, terus-menerus mempertahankan nada, dan tentu saja tidak membuat Anda bosan. OpenStack jelas bukan cintaku pada pandangan pertama, direduksi menjadi kepanasan dan pingsan, tapi itu jelas layak mendapatkan sedikit cinta sekarang. Dan jika Anda siap untuk hampir menyentuh dengan sentuhan melalui kegelapan konsol, didorong oleh kebutuhan untuk menyadari diri sendiri (dan membuat dunia open-source sedikit lebih baik), mungkin inilah cara Anda.