[ English | Indonesia | Deutsch | 日本語 ]

Merencanakan untuk menggunakan dan menyediakan OpenStack

Keputusan yang Anda buat sehubungan dengan penyediaan dan penyebaran akan memengaruhi pemeliharaan cloud Anda. Manajemen konfigurasi Anda akan dapat berkembang seiring waktu. Namun, lebih banyak pemikiran dan desain perlu dilakukan untuk pilihan awal tentang penyebaran, partisi disk, dan konfigurasi jaringan.

Bagian penting dari skalabilitas cloud adalah jumlah upaya yang diperlukan untuk menjalankan cloud Anda. Untuk meminimalkan biaya operasional menjalankan cloud Anda, atur dan gunakan penyebaran otomatis dan infrastruktur konfigurasi dengan sistem manajemen konfigurasi, seperti Puppet atau Chef. Digabungkan, sistem ini sangat mengurangi upaya manual dan kemungkinan kesalahan operator.

Infrastruktur ini mencakup sistem untuk secara otomatis menginstal konfigurasi awal sistem operasi dan kemudian mengoordinasikan konfigurasi semua layanan secara otomatis dan terpusat, yang mengurangi upaya manual dan kemungkinan kesalahan. Contohnya termasuk Ansible, CFEngine, Chef, Puppet, dan Salt. Anda bahkan dapat menggunakan OpenStack untuk menggunakan OpenStack, bernama TripleO (OpenStack On OpenStack).

Penyebaran otomatis

Sistem penyebaran otomatis menginstal dan mengkonfigurasi sistem operasi pada server baru, tanpa intervensi, setelah jumlah minimum absolut dari pekerjaan manual, termasuk pemerasan fisik, penugasan MAC-ke-IP, dan konfigurasi daya. Biasanya, solusi mengandalkan pembungkus (wrapper) di sekitar boot PXE dan server TFTP untuk instalasi sistem operasi dasar dan kemudian diserahkan ke sistem manajemen konfigurasi otomatis.

Ubuntu dan Red Hat Enterprise Linux menyertakan mekanisme untuk mengkonfigurasi sistem operasi, termasuk preseed dan kickstart, yang dapat Anda gunakan setelah boot jaringan. Biasanya, ini digunakan untuk mem-bootstrap sistem konfigurasi otomatis. Atau, Anda dapat menggunakan pendekatan berbasis image untuk menggunakan sistem operasi, seperti systemimager. Anda dapat menggunakan kedua pendekatan dengan infrastruktur tervirtualisasi, seperti ketika Anda menjalankan VM untuk memisahkan layanan kontrol dan infrastruktur fisik Anda.

Saat Anda membuat rencana penempatan, fokuslah pada beberapa area penting karena sangat sulit untuk memodifikasi penempatan setelah itu. Dua bagian berikutnya berbicara tentang konfigurasi untuk:

• Partisi disk dan pengaturan array disk untuk skalabilitas

• Konfigurasi jaringan hanya untuk boot PXE

Partisi disk dan RAID

Di bagian paling dasar dari setiap sistem operasi adalah hard drive tempat sistem operasi (OS) diinstal.

Anda harus menyelesaikan konfigurasi berikut pada hard drive server:

• Partisi, yang memberikan fleksibilitas lebih besar untuk tata letak sistem operasi dan ruang swap, seperti dijelaskan di bawah ini.

• Menambah array RAID (RAID adalah singkatan dari redundant array of independent disks), berdasarkan jumlah disk yang Anda miliki, sehingga Anda dapat menambah kapasitas saat cloud Anda tumbuh. Beberapa opsi dijelaskan secara lebih rinci di bawah ini.

Opsi paling sederhana untuk memulai adalah menggunakan satu hard drive dengan dua partisi:

• Sistem file untuk menyimpan file dan direktori, tempat semua data hidup, termasuk partisi root yang memulai dan menjalankan sistem.

• Tukar ruang untuk membebaskan memori untuk proses, sebagai area independen dari disk fisik yang hanya digunakan untuk bertukar dan tidak ada yang lain.

RAID tidak digunakan dalam pengaturan satu drive yang sederhana ini karena umumnya untuk cloud produksi, Anda ingin memastikan bahwa jika satu disk gagal, disk lain dapat menggantikannya. Sebagai gantinya, untuk produksi, gunakan lebih dari satu disk. Jumlah disk menentukan jenis array RAID yang akan dibuat.

Kami menyarankan Anda memilih salah satu dari beberapa opsi disk berikut:

Opsi 1

Partisi semua drive dengan cara yang sama secara horizontal, seperti yang ditunjukkan pada Pengaturan partisi drive.

Dengan opsi ini, Anda dapat menetapkan partisi yang berbeda untuk array RAID yang berbeda. Anda dapat mengalokasikan partisi 1 disk satu dan dua ke cermin partisi /boot . Anda dapat menjadikan partisi 2 dari semua disk sebagai partisi root. Anda dapat menggunakan partisi 3 dari semua disk untuk partisi LVM cinder-volume yang berjalan pada array RAID 10.

Pengaturan partisi drive

Meskipun Anda mungkin berakhir dengan partisi yang tidak digunakan, seperti partisi 1 di disk tiga dan empat dari contoh ini, opsi ini memungkinkan pemanfaatan ruang disk secara maksimal. Kinerja I/O mungkin menjadi masalah karena semua disk digunakan untuk semua tugas.

Opsi 2

Tambahkan semua disk baku ke satu array RAID besar, baik berbasis perangkat keras atau perangkat lunak. Anda dapat mempartisi array besar ini dengan area boot, root, swap, dan LVM. Opsi ini mudah diterapkan dan menggunakan semua partisi. Namun, disk I/O mungkin terbebani.

Opsi 3

Dedikasikan seluruh disk untuk partisi tertentu. Misalnya, Anda bisa mengalokasikan disk satu dan dua seluruhnya untuk partisi boot, root, dan swap di bawah mirror RAID 1. Kemudian, alokasikan disk tiga dan empat seluruhnya ke partisi LVM, juga di bawah mirror RAID 1. Disk I/O harus lebih baik karena I/O fokus pada tugas khusus. Namun, partisi LVM jauh lebih kecil.

Tip

Anda mungkin menemukan bahwa Anda dapat mengotomatisasi partisi itu sendiri. Sebagai contoh, MIT menggunakan Fully Automatic Installation (FAI) <http://fai-project.org/> _ untuk melakukan partisi awal berbasis PXE dan kemudian menginstal menggunakan kombinasi dari partisi min/max dan berbasis persentase.

As with most architecture choices, the right answer depends on your environment. If you are using existing hardware, you know the disk density of your servers and can determine some decisions based on the options above. If you are going through a procurement process, your user's requirements also help you determine hardware purchases. Here are some examples from a private cloud providing web developers custom environments at AT&T. This example is from a specific deployment, so your existing hardware or procurement opportunity may vary from this. AT&T uses three types of hardware in its deployment:

• Perangkat keras untuk node pengontrol, digunakan untuk semua layanan OpenStack API stateless. Tentang memori 32–64 GB, disk kecil yang terpasang, satu prosesor, jumlah core yang bervariasi, seperti 6-12.

• Perangkat keras untuk komputasi node. Biasanya memori 256 atau 144 GB, dua prosesor, 24 core. Penyimpanan langsung terpasang 4–6 TB, biasanya dalam konfigurasi RAID 5.

• Perangkat keras untuk node penyimpanan. Biasanya untuk ini, ruang disk dioptimalkan untuk biaya terendah per GB penyimpanan sambil mempertahankan efisiensi ruang rak (rack-space).

Sekali lagi, jawaban yang tepat tergantung pada lingkungan Anda. Anda harus membuat keputusan berdasarkan pertukaran antara pemanfaatan ruang, kesederhanaan, dan kinerja I/O.

Konfigurasi jaringan

Konfigurasi jaringan adalah topik yang sangat besar yang mencakup beberapa area buku ini. Untuk saat ini, pastikan server Anda dapat melakukan PXE booting dan berhasil berkomunikasi dengan server deployment.

Misalnya, Anda biasanya tidak dapat mengonfigurasi NIC untuk VLAN saat PXE boot. Selain itu, Anda biasanya tidak dapat melakukan PXE boot dengan NIC terikat. Jika Anda mengalami skenario ini, pertimbangkan untuk menggunakan switch 1 GB sederhana di jaringan pribadi tempat cloud Anda berkomunikasi.

Konfigurasi otomatis

Tujuan dari manajemen konfigurasi otomatis adalah untuk membangun dan memelihara konsistensi sistem tanpa menggunakan intervensi manusia. Anda ingin mempertahankan konsistensi dalam penerapan Anda sehingga Anda dapat memiliki cloud yang sama setiap saat, berulang-ulang. Penggunaan yang tepat dari alat manajemen konfigurasi otomatis memastikan bahwa komponen sistem cloud berada dalam kondisi tertentu, selain menyederhanakan deployment, dan propagasi perubahan konfigurasi.

Alat-alat ini juga memungkinkan untuk menguji dan mengembalikan perubahan, karena sepenuhnya dapat diulang. Dengan mudah, banyak pekerjaan telah dilakukan oleh komunitas OpenStack di ruang ini. Puppet, alat manajemen konfigurasi, bahkan menyediakan modul resmi untuk proyek OpenStack dalam sistem infrastruktur OpenStack yang dikenal sebagai Puppet OpenStack <https://wiki.openstack.org/wiki/Puppet> _. Manajemen konfigurasi chef disediakan dalam OpenStack Chef Repo <https://opendev.org/openstack/openstack-chef-repo> _. Sistem manajemen konfigurasi tambahan termasuk Juju, Ansible, dan Salt. Juga, PackStack adalah utilitas baris perintah untuk Red Hat Enterprise Linux dan turunannya yang menggunakan modul Puppet untuk mendukung penyebaran OpenStack yang cepat pada server yang ada melalui koneksi SSH.

Bagian integral dari sistem manajemen konfigurasi adalah item yang dikontrolnya. Anda harus hati-hati mempertimbangkan semua item yang Anda inginkan, atau tidak ingin, dikelola secara otomatis. Misalnya, Anda mungkin tidak ingin memformat hard drive dengan data pengguna secara otomatis.

Manajemen jarak jauh

Dalam pengalaman kami, sebagian besar operator tidak duduk tepat di sebelah server yang menjalankan cloud, dan banyak yang tidak selalu menikmati mengunjungi pusat data. OpenStack harus sepenuhnya dapat dikonfigurasi dari jarak jauh, tetapi terkadang tidak semuanya berjalan sesuai rencana.

Dalam instance ini, memiliki akses out-of-band ke node yang menjalankan komponen OpenStack adalah suatu anugerah. Protokol IPMI adalah standar de facto di sini, dan memperoleh perangkat keras yang mendukungnya sangat disarankan untuk mencapai tujuan pusat data yang padam (lights-out).

Selain itu, pertimbangkan juga kendali daya jarak jauh. Sementara IPMI biasanya mengontrol status daya server, memiliki akses jarak jauh ke PDU yang tersambung ke server benar-benar dapat berguna untuk situasi ketika semuanya tampak terjepit (wedged).

Pertimbangan lainnya

Anda dapat menghemat waktu dengan memahami kasus penggunaan untuk cloud yang ingin Anda buat. Kasus penggunaan untuk OpenStack bervariasi. Beberapa hanya menyertakan penyimpanan objek; yang lain membutuhkan sumber daya komputasi yang telah dikonfigurasikan sebelumnya untuk mempercepat pengaturan lingkungan pengembangan; dan yang lainnya membutuhkan penyediaan sumber daya komputasi yang cepat yang sudah diamankan per penyewa dengan jaringan pribadi. Pengguna Anda mungkin perlu server yang sangat berlebihan untuk memastikan aplikasi lawas mereka terus berjalan. Mungkin tujuannya adalah untuk merancang aplikasi-aplikasi warisan ini sehingga aplikasi-aplikasi tersebut dijalankan pada banyak instance di cloud, secara toleran kesalahan, tetapi tidak menjadikannya suatu tujuan untuk ditambahkan ke kluster-kluster tersebut dari waktu ke waktu. Pengguna Anda mungkin mengindikasikan bahwa mereka perlu pertimbangan penskalaan karena penggunaan server Windows yang berat.

Anda dapat menghemat sumber daya dengan melihat yang paling cocok untuk perangkat keras yang Anda miliki. Anda mungkin memiliki beberapa perangkat keras penyimpanan kepadatan tinggi yang tersedia. Anda bisa memformat dan menggunakan kembali server-server itu untuk OpenStack Object Storage. Semua pertimbangan dan masukan dari pengguna ini membantu Anda membangun kasus penggunaan (use case) dan rencana penerapan Anda.

Tip

Untuk penelitian lebih lanjut tentang penyebaran OpenStack, selidiki installer prakonfigurasi yang didukung dan didokumentasikan, yang telah dikemas untuk OpenStack dari perusahaan seperti Canonical, Cisco, Cloudscaling, IBM, Metacloud, Mirantis, Rackspace, Red Hat, SUSE, dan SwiftStack.