[ English | русский | Deutsch | 한국어 (대한민국) | English (United Kingdom) | Indonesia ]
Quickstart: AIO¶
Pembuatan All-in-one (AIO) adalah cara yang bagus untuk melakukan pembangunan OpenStack-Ansible untuk:
lingkungan pengembangan
gambaran umum tentang bagaimana semua layanan OpenStack cocok bersama
penyebaran laboratorium sederhana
Meskipun build AIO tidak direkomendasikan untuk penyebaran produksi besar, mereka sangat bagus untuk penyebaran konsep-konsep yang lebih kecil.
Sumber daya server minimum absolut (saat ini digunakan untuk pemeriksaan gate):
8 vCPU's
Ruang disk kosong 50GB pada partisi root
8GB RAM
Sumber daya server yang direkomendasikan:
CPU/motherboard yang mendukung hardware-assisted virtualization
8 CPU Cores
80GB ruang kosong pada partisi root, atau 60GB + pada disk sekunder kosong. Menggunakan disk sekunder membutuhkan penggunaan parameter
bootstrap_host_data_disk_device. Silakan lihat Building an AIO untuk detail lebih lanjut.16GB RAM
Sangat mungkin untuk melakukan build AIO di dalam mesin virtual untuk demonstrasi dan evaluasi, tetapi mesin virtual Anda akan berkinerja buruk kecuali jika tersedia virtualisasi bersarang. Untuk beban kerja produksi, beberapa node untuk role tertentu direkomendasikan.
Membangun AIO¶
Ikhtisar¶
Ada tiga langkah untuk menjalankan build AIO, dengan langkah pertama opsional jika Anda perlu menyesuaikan build Anda:
Siapkan host
Bootstrap Ansible dan role yang diperlukan
Bootstrap konfigurasi AIO
Jalankan playbook
Siapkan host¶
Ketika membangun AIO di server baru, disarankan agar semua paket sistem ditingkatkan dan kemudian reboot ke kernel baru:
Catatan
Jalankan perintah dan skrip berikut sebagai pengguna root.
## Ubuntu
# apt-get update
# apt-get dist-upgrade
# reboot
## CentOS
# yum upgrade
# yum install git
# reboot
Catatan
Sebelum mem-boot ulang, di /etc/sysconfig/selinux, pastikan bahwa SELINUX=enforcing``is changed to ``SELINUX=disabled. SELinux yang diaktifkan saat ini tidak didukung di OpenStack-Ansible untuk CentOS/RHEL karena kurangnya pengelola untuk fitur ini.
## openSUSE
# zypper up
# zypper in git-core
# reboot
Catatan
Jika Anda menginstal dengan konektivitas terbatas, silakan tinjau lampiran Installing with limited connectivity dalam Deployment Guide sebelum melanjutkan.
Bootstrap Ansible dan role yang diperlukan¶
Mulailah dengan menggandakan repositori OpenStack-Ansible dan mengubah ke direktori root repositori:
# git clone https://opendev.org/openstack/openstack-ansible \
/opt/openstack-ansible
# cd /opt/openstack-ansible
Selanjutnya, pindahkan branch/tag yang berlaku untuk dikerahkan. Perhatikan bahwa penerapan dari kepala cabang (head of a branch) dapat mengakibatkan pembangunan yang tidak stabil karena perubahan dalam flight dan perubahan OpenStack di hulu. Untuk tes (misalnya, bukan pengembangan) membangunnya biasanya lebih baik untuk memeriksa versi tag terbaru.
# # List all existing tags. # git tag -l # # Checkout the stable branch and find just the latest tag # git checkout stable/train # git describe --abbrev=0 --tags # # Checkout the latest tag from either method of retrieving the tag. # git checkout 20.2.7
Catatan
The Train release is only compatible with Debian 9 (stretch), Debian 10 (buster), Ubuntu 18.04 (Bionic Beaver), CentOS 7 and openSUSE Leap 15.X.
Langkah selanjutnya adalah untuk bootstrap Ansible dan peran Ansible untuk lingkungan pengembangan.
Jalankan berikut ini untuk bootstrap Ansible dan peran (role) yang diperlukan:
# scripts/bootstrap-ansible.sh
Catatan
Anda mungkin mengalami kesalahan saat menjalankan skrip bootstrap Ansible saat membuat beberapa ekstensi Python (seperti pycrypto) yang mengatakan:
configure: error: cannot run C compiled programs.
Alasan kegagalan ini mungkin disebabkan oleh flag mount noexec yang digunakan untuk filesystem yang terkait dengan /tmp yang dapat Anda periksa dengan menjalankan perintah berikut:
# mount | grep $(df /tmp | tail -n +2 | awk '{print $1}') | grep noexec
Jika ini adalah kasus Anda dapat menentukan jalur alternatif yang tidak memiliki opsi mount ini diatur:
# TMPDIR=/var/tmp scripts/bootstrap-ansible.sh
Bootstrap konfigurasi AIO¶
Agar semua layanan berjalan, host harus dipersiapkan dengan partisi disk, paket, konfigurasi jaringan dan konfigurasi yang tepat untuk OpenStack Deployment.
Secara default skrip bootstrap AIO menggunakan set dasar layanan OpenStack dengan default yang masuk akal untuk tujuan pemeriksaan gerbang (gate check), pengembangan atau sistem pengujian.
Tinjau strstrstrap-host role defaults file untuk melihat berbagai opsi konfigurasi. Deployer memiliki opsi untuk mengubah cara host ditopang bootstrap. Ini berguna ketika Anda ingin AIO menggunakan disk data sekunder, atau ketika menggunakan peran ini untuk bootstrap lingkungan pengembangan multi-node.
Skrip bootstrap telah ditetapkan sebelumnya untuk meneruskan variabel lingkungan BOOTSTRAP_OPTS sebagai opsi tambahan untuk proses bootstrap. Misalnya, jika Anda ingin mengatur bootstrap untuk mempartisi ulang perangkat penyimpanan sekunder khusus (/dev/sdb), yang akan menghapus semua data pada perangkat, kemudian jalankan:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
Opsi tambahan dapat diimplementasikan hanya dengan menggabungkannya dengan spasi di antara setiap rangkaian opsi, misalnya:
# export BOOTSTRAP_OPTS="bootstrap_host_data_disk_device=sdb"
# export BOOTSTRAP_OPTS="${BOOTSTRAP_OPTS} bootstrap_host_data_disk_fs_type=xfs"
Untuk skenario AIO default, persiapan konfigurasi AIO akan selesai dengan mengeksekusi:
# scripts/bootstrap-aio.sh
Untuk menambahkan OpenStack Service di atas dan di atas layanan default bootstrap-aio untuk skenario yang berlaku, salin file conf.d dengan ekstensi file `` .aio`` ke /etc/openstack_deploy dan ganti nama kemudian ke file .yml. Misalnya, untuk mengaktifkan layanan Telemetri OpenStack, jalankan yang berikut:
# cd /opt/openstack-ansible/
# cp etc/openstack_deploy/conf.d/{aodh,gnocchi,ceilometer}.yml.aio /etc/openstack_deploy/conf.d/
# for f in $(ls -1 /etc/openstack_deploy/conf.d/*.aio); do mv -v ${f} ${f%.*}; done
Dimungkinkan juga untuk melakukan ini (dan mengubah default lainnya) selama eksekusi awal skrip bootstrap dengan mengubah variabel lingkungan SCENARIO sebelum menjalankan skrip. Kata kunci 'aio' akan memastikan bahwa serangkaian dasar layanan OpenStack (cinder, glance, horizon, neutron, nova) akan digunakan. Kata-kata kunci 'lxc' dan 'nspawn' dapat digunakan untuk mengatur back-end container, sedangkan kata kunci 'metal' akan menyebarkan semua layanan tanpa container. Untuk menerapkan layanan lain, tambahkan nama nama file conf.d tanpa ekstensi .yml.aio ke dalam variabel lingkungan SCENARIO. Setiap kata kunci harus dibatasi oleh garis bawah. Sebagai contoh, berikut ini akan menerapkan AIO dengan barbican, cinder, glance, horizon, neutron, dan nova. Ini akan mengatur back-end penyimpanan cinder ke ceph dan akan menggunakan LXC sebagai back-end container.
# export SCENARIO='aio_lxc_barbican_ceph'
# scripts/bootstrap-aio.sh
Catatan
Jika kata kunci 'metal' dan 'aio' digunakan bersama-sama, horizon tidak akan digunakan karena haproxy dan horizon akan konflik pada port mendengarkan yang sama.
Untuk menambahkan global override, melebihi dan di atas default untuk skenario yang berlaku, edit /etc/openstack_deploy/user_variables.yml. Untuk memahami berbagai cara agar Anda dapat menimpa perilaku default yang ditetapkan dalam variabel role, playbook, dan grup, lihat Mengganti konfigurasi default.
Lihat Deployment Guide untuk perincian yang lebih rinci tentang bagaimana menerapkan konfigurasi Anda sendiri daripada menggunakan bootstrap AIO.
Jalankan playbook¶
Akhirnya, jalankan playbook dengan mengeksekusi:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible setup-hosts.yml
# openstack-ansible setup-infrastructure.yml
# openstack-ansible setup-openstack.yml
Proses instalasi akan memakan waktu cukup lama untuk diselesaikan, tetapi berikut adalah beberapa perkiraan umum:
Sistem bare metal dengan penyimpanan SSD: ~ 30-50 menit
Mesin virtual dengan penyimpanan SSD: ~ 45-60 menit
Sistem dengan hard disk tradisional: ~ 90-120 menit
Setelah playbook sepenuhnya dieksekusi, adalah mungkin untuk bereksperimen dengan berbagai perubahan pengaturan di /etc/openstack_deploy/user_variables.yml dan hanya menjalankan playbook individu. Misalnya, untuk menjalankan pedoman untuk layanan Keystone, laksanakan:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible os-keystone-install.yml
Mem-boot ulang AIO¶
Karena AIO mencakup ketiga anggota cluster MariaDB/Galera, cluster harus diinisialisasi ulang setelah host di-reboot.
Ini dilakukan dengan mengeksekusi yang berikut:
# cd /opt/openstack-ansible/playbooks
# openstack-ansible -e galera_ignore_cluster_state=true galera-install.yml
Jika ini gagal untuk mendapatkan kembali cluster database ke keadaan berjalan, maka silakan gunakan bagian Galera Cluster Recovery </admin/maintenance-tasks.html#galera-cluster-recovery> di panduan operasi.
Membangun kembali AIO¶
Kadang-kadang mungkin berguna untuk menghancurkan semua kontainer dan membangun kembali AIO. Meskipun lebih disukai bahwa AIO sepenuhnya dihancurkan dan dibangun kembali, ini tidak selalu praktis. Karena itu, hal-hal berikut dapat dieksekusi sebagai gantinya:
# # Move to the playbooks directory.
# cd /opt/openstack-ansible/playbooks
# # Destroy all of the running containers.
# openstack-ansible lxc-containers-destroy.yml
# # On the host stop all of the services that run locally and not
# # within a container.
# for i in \
$(ls /etc/init \
| grep -e "nova\|swift\|neutron\|cinder" \
| awk -F'.' '{print $1}'); do \
service $i stop; \
done
# # Uninstall the core services that were installed.
# for i in $(pip freeze | grep -e "nova\|neutron\|keystone\|swift\|cinder"); do \
pip uninstall -y $i; done
# # Remove crusty directories.
# rm -rf /openstack /etc/{neutron,nova,swift,cinder} \
/var/log/{neutron,nova,swift,cinder}
# # Remove the pip configuration files on the host
# rm -rf /root/.pip
# # Remove the apt package manager proxy
# rm /etc/apt/apt.conf.d/00apt-cacher-proxy
Jika lingkungan AIO yang ada perlu diinstal ulang, metode yang paling efisien adalah menghancurkan sistem operasi host dan memulai kembali. Untuk alasan ini, AIO paling baik dijalankan di dalam beberapa bentuk mesin virtual (virtual machine) atau cloud guest.
Referensi Diagram untuk AIO Build¶
Berikut ini adalah diagram dasar yang mencoba untuk menggambarkan apa yang dihasilkan penyebaran AIO yang dihasilkan.
Diagram ini tidak untuk skala dan bahkan tidak 100% akurat, diagram ini dibangun hanya untuk tujuan informasi dan seharusnya ONLY digunakan seperti itu.
------->[ ETH0 == Public Network ]
|
V [ * ] Socket Connections
[ HOST MACHINE ] [ <>v^ ] Network Connections
* ^ *
| | |-------------------------------------------------------
| | |
| |---------------->[ HAProxy ] |
| ^ |
| | |
| V |
| (BR-Interfaces)<------ |
| ^ * | |
*-[ LXC ]*--*----------------------|-----|------|----| |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | V * | |
| * | | [ Galera x3 ] |
| [ Memcached ]<------------| | | |
*-------*[ Rsyslog ]<--------------|--| | * |
| [ Repos Server x3 ]<------| ---|-->[ RabbitMQ x3 ] |
| [ Horizon x2 ]<-----------| | | |
| [ Nova api ec2 ]<---------|--| | |
| [ Nova api os ]<----------|->| | |
| [ Nova console ]<---------| | | |
| [ Nova Cert ]<------------|->| | |
| [ Cinder api ]<-----------|->| | |
| [ Glance api ]<-----------|->| | |
| [ Heat apis ]<------------|->| | [ Loop back devices ]*-*
| [ Heat engine ]<----------|->| | \ \ |
| ------>[ Nova api metadata ] | | | { LVM } { XFS x3 } |
| | [ Nova conductor ]<-------| | | * * |
| |----->[ Nova scheduler ]--------|->| | | | |
| | [ Keystone x3 ]<----------|->| | | | |
| | |--->[ Neutron agents ]*-------|--|---------------------------*
| | | [ Neutron server ]<-------|->| | | |
| | | |->[ Swift proxy ]<----------- | | | |
*-|-|-|-*[ Cinder volume ]*----------------------* | |
| | | | | | |
| | | ----------------------------------------- | |
| | ----------------------------------------- | | |
| | -------------------------| | | | |
| | | | | | |
| | V | | * |
---->[ Compute ]*[ Neutron linuxbridge ]<---| |->[ Swift storage ]-
