[ English | Indonesia | Deutsch | 日本語 ]

Konfigurasi Lanjutan

OpenStack dimaksudkan untuk bekerja dengan baik di berbagai flavor instalasi, dari awan pribadi yang sangat kecil hingga awan publik yang besar. Untuk mencapai ini, pengembang menambahkan opsi konfigurasi ke kode mereka yang memungkinkan perilaku berbagai komponen untuk di-tweak tergantung pada kebutuhan Anda. Sayangnya, tidak mungkin untuk mencakup semua kemungkinan penyebaran dengan nilai konfigurasi default.

Pada saat penulisan, OpenStack memiliki lebih dari 3.000 opsi konfigurasi. Anda dapat melihatnya didokumentasikan di OpenStack Configuration Reference. Bab ini tidak dapat berharap untuk mendokumentasikan semua ini, tetapi kami mencoba memperkenalkan konsep-konsep penting sehingga Anda tahu ke mana harus mencari informasi lebih lanjut.

Perbedaan Antara Berbagai Driver

Banyak proyek OpenStack menerapkan lapisan driver, dan masing-masing driver ini akan menerapkan opsi konfigurasi sendiri. Sebagai contoh, dalam OpenStack Compute (nova), ada berbagai driver hypervisor yang diimplementasikan — libvirt, xenserver, hyper-v, dan vmware, misalnya. Tidak semua driver hypervisor ini memiliki fitur yang sama, dan masing-masing memiliki persyaratan penyetelan yang berbeda.

Catatan

Hypervisor yang saat ini diterapkan tercantum pada OpenStack Configuration Reference <https://docs.openstack.org/ocata/config-reference/compute/hypervisors.html> __. Anda dapat melihat matriks berbagai fitur di driver hypervisor OpenStack Compute (nova) di Hypervisor support matrix page.

Poin yang kami coba sampaikan di sini adalah hanya karena ada opsi, tidak berarti opsi itu relevan dengan pilihan driver Anda. Biasanya, dokumentasi mencatat driver yang berlaku untuk konfigurasi.

Menerapkan Tugas Berkala

Konsep umum lainnya di berbagai proyek OpenStack adalah tugas berkala. Tugas berkala mirip dengan pekerjaan cron pada sistem Unix tradisional, tetapi dijalankan di dalam proses OpenStack. Sebagai contoh, ketika OpenStack Compute (nova) perlu mencari image apa yang dapat dihapus dari cache lokal, itu menjalankan tugas berkala untuk melakukan ini.

Tugas berkala penting untuk dipahami karena keterbatasan dalam model threading yang digunakan OpenStack. OpenStack menggunakan threading kooperatif dalam Python, yang berarti bahwa jika sesuatu yang panjang dan rumit berjalan, itu akan memblokir tugas-tugas lain di dalam proses itu dari berjalan kecuali itu secara sukarela menghasilkan eksekusi ke thread kooperatif lain.

Contoh nyata dari ini adalah proses nova-compute. Untuk mengelola cache image dengan libvirt, nova-compute memiliki proses periodik yang memindai isi cache image. Bagian dari pemindaian ini menghitung checksum untuk setiap image dan memastikan bahwa checksum cocok dengan apa yang diharapkan oleh nova-compute. Namun, image bisa sangat besar, dan checksum ini dapat memakan waktu lama untuk dibuat. Pada satu titik, sebelum dilaporkan sebagai bug dan diperbaiki, nova-compute akan memblokir tugas ini dan berhenti merespons permintaan RPC. Ini terlihat oleh pengguna sebagai kegagalan operasi seperti memijah atau menghapus instance.

Kelemahan dari ini adalah jika Anda mengamati proses OpenStack yang tampaknya "stop" untuk sementara waktu dan kemudian melanjutkan proses secara normal, Anda harus memeriksa bahwa tugas-tugas berkala bukanlah masalahnya. Salah satu cara untuk melakukan ini adalah menonaktifkan tugas berkala dengan mengatur intervalnya ke nol. Selain itu, Anda dapat mengonfigurasi seberapa sering tugas-tugas berkala ini dijalankan — dalam beberapa kasus, mungkin masuk akal untuk menjalankannya pada frekuensi yang berbeda dari standarnya.

Frekuensi didefinisikan secara terpisah untuk setiap tugas berkala. Oleh karena itu, untuk menonaktifkan setiap tugas berkala di OpenStack Compute (nova), Anda perlu mengatur sejumlah opsi konfigurasi ke nol. Daftar opsi konfigurasi saat ini yang perlu Anda atur ke nol adalah:

  • bandwidth_poll_interval

  • sync_power_state_interval

  • heal_instance_info_cache_interval

  • host_state_interval

  • image_cache_manager_interval

  • reclaim_instance_interval

  • volume_usage_poll_interval

  • shelved_poll_interval

  • shelved_offload_time

  • instance_delete_interval

Untuk mengatur opsi konfigurasi ke nol, sertakan baris seperti file image_cache_manager_interval=0 in your nova.conf.

Daftar ini akan berubah di antara rilis, jadi silakan merujuk ke panduan konfigurasi Anda untuk informasi terbaru.

Topik Konfigurasi Khusus

Bagian ini mencakup contoh spesifik opsi konfigurasi yang dapat Anda pertimbangkan untuk penyetelan. Ini tidak berarti daftar lengkap.

Konfigurasi Keamanan untuk Komputasi, Jaringan, dan Penyimpanan

The OpenStack Security Guide menyediakan penyelaman mendalam untuk mengamankan cloud OpenStack, termasuk SSL/TLS, manajemen utama, PKI dan manajemen sertifikat, transportasi data dan masalah privasi, dan kepatuhan.

Ketersediaan Tinggi

The OpenStack High Availability Guide menawarkan saran untuk menghilangkan satu titik kegagalan yang dapat menyebabkan gangguan sistem. Meskipun ini bukan dokumen yang sepenuhnya preskriptif, ia menawarkan metode dan teknik untuk menghindari downtime dan kehilangan data.

Mengaktifkan Dukungan IPv6

Anda dapat mengikuti kemajuan yang dibuat pada dukungan IPV6 dengan melihat neutron IPv6 Subteam at work.

Dengan memodifikasi pengaturan konfigurasi Anda, Anda dapat mengatur IPv6 saat menggunakan nova-network untuk jaringan, dan pengaturan yang diuji didokumentasikan untuk FlatDHCP dan konfigurasi multi-host. Kuncinya adalah membuat nova-network berpikir perintah radvd berhasil dijalankan. Seluruh konfigurasi dirinci dalam posting blog Cybera, “An IPv6 enabled cloud”.

Pertimbangan Geografis untuk Object Storage

Dukungan untuk pengelompokan global server penyimpanan objek tersedia untuk semua rilis yang didukung. Anda akan mengimplementasikan kluster global ini untuk memastikan replikasi di seluruh wilayah geografis jika terjadi bencana alam dan juga untuk memastikan bahwa pengguna dapat menulis atau mengakses objek mereka lebih cepat berdasarkan pusat data terdekat. Anda mengonfigurasikan wilayah default dengan satu zona untuk setiap cluster, tetapi pastikan jaringan Anda (WAN) dapat menangani permintaan tambahan dan respons di antara zona saat Anda menambahkan lebih banyak zona dan membangun cincin yang menangani lebih banyak zona. Mengacu pada Geographically Distributed Swift Considerations dalam dokumentasi untuk informasi tambahan.