[ English | Indonesia | Deutsch | 日本語 ]

Perencanaan dan penskalaan kapasitas

Aplikasi berbasis cloud biasanya meminta lebih banyak perangkat keras diskrit (penskalaan horizontal) sebagai kebalikan dari aplikasi tradisional, yang membutuhkan perangkat keras yang lebih besar untuk skala (penskalaan vertikal).

OpenStack dirancang untuk dapat diskalakan secara horizontal. Daripada beralih ke server yang lebih besar, Anda membeli lebih banyak server dan cukup menginstal layanan yang dikonfigurasikan secara identik. Idealnya, Anda memperbesar dan memuat keseimbangan di antara grup layanan yang identik secara fungsional (misalnya, komputasi node atau node nova-api), yang berkomunikasi pada bus pesan (message bus).

Menentukan skalabilitas cloud

Menentukan skalabilitas cloud Anda dan cara memperbaikinya memerlukan penyeimbangan banyak variabel. Tidak ada solusi yang memenuhi sasaran skalabilitas semua orang. Namun, melacak sejumlah metrik bermanfaat. Anda dapat mendefinisikan template perangkat keras virtual yang disebut "flavors" di OpenStack, yang akan memengaruhi keputusan penskalaan cloud Anda. Template ini menentukan ukuran untuk memori dalam RAM, ukuran disket root, jumlah ruang disk data sementara yang tersedia, dan jumlah core CPU.

Flavor OpenStack default ditampilkan di :ref: table_default_flavours.

Table. flavor standar OpenStack

Name	Virtual cores	Memory	Disk	Ephemeral
m1.tiny	1	512 MB	1 GB	0 GB
m1.small	1	2 GB	10 GB	20 GB
m1.medium	2	4 GB	10 GB	40 GB
m1.large	4	8 GB	10 GB	80 GB
m1.xlarge	8	16 GB	10 GB	160 GB

Titik awalnya adalah jumlah core cloud Anda. Dengan menerapkan beberapa rasio, Anda dapat mengumpulkan informasi tentang:

• Jumlah virtual machine (VM) yang Anda harapkan untuk dijalankan, ``((overcommit fraction × cores) / virtual cores per instance)`

• Berapa banyak penyimpanan yang dibutuhkan (flavor disk size × number of instances)

Anda dapat menggunakan rasio ini untuk menentukan berapa banyak infrastruktur tambahan yang Anda butuhkan untuk mendukung cloud Anda.

Berikut adalah contoh menggunakan rasio untuk mengumpulkan informasi skalabilitas untuk jumlah VM yang diharapkan serta penyimpanan yang dibutuhkan. Angka-angka berikut ini mendukung (200/2) × 16 = 1600 VM instance dan membutuhkan penyimpanan 80 TB untuk /var/lib/nova/instances:

• 200 physical cores.

• Sebagian besar instance adalah ukuran m1.medium (dua core virtual, 50 GB penyimpanan).

• Rasio overcommit CPU default (cpu_allocation_ratio dalam file nova.conf) dari 16: 1.

Catatan

Terlepas dari rasio overcommit, sebuah instance tidak dapat ditempatkan pada setiap node fisik dengan sumber daya (pre-overcommit) mentah yang lebih sedikit daripada yang dibutuhkan oleh instance flavor.

Namun, Anda membutuhkan lebih dari jumlah core saja untuk memperkirakan beban yang mungkin dihadapi oleh layanan API, server database, dan server antrian. Anda juga harus mempertimbangkan pola penggunaan cloud Anda.

Sebagai contoh spesifik, bandingkan cloud yang mendukung platform hosting web yang dikelola dengan satu yang menjalankan tes integrasi untuk proyek pengembangan yang membuat satu VM per komit kode. Dalam yang pertama, pekerjaan berat menciptakan VM terjadi hanya setiap beberapa bulan, sedangkan yang terakhir menempatkan beban berat konstan pada pengendali cloud. Anda harus mempertimbangkan masa pakai VM rata-rata, karena jumlah yang lebih besar umumnya berarti lebih sedikit beban pada pengontrol cloud.

Selain pembuatan dan penghentian VM, Anda harus mempertimbangkan dampak dari pengguna yang mengakses layanan khususnya pada nova-api dan database terkaitnya. Mendaftar instance mengumpulkan banyak informasi dan, mengingat frekuensi pengguna menjalankan operasi ini, cloud dengan sejumlah besar pengguna dapat meningkatkan beban secara signifikan. Ini dapat terjadi bahkan tanpa sepengetahuan mereka. Misalnya, membiarkan tab instance dasbor OpenStack terbuka di browser menyegarkan daftar VM setiap 30 detik.

Setelah Anda mempertimbangkan faktor-faktor ini, Anda dapat menentukan berapa banyak core pengontrol cloud yang Anda butuhkan. Server delapan core, 8 GB RAM biasanya cukup untuk satu rak node komputasi - mengingat peringatan di atas.

Anda juga harus mempertimbangkan spesifikasi perangkat keras utama untuk kinerja VM pengguna, serta kebutuhan anggaran dan kinerja, termasuk kinerja penyimpanan (spindles/core), ketersediaan memori (RAM/core), spesifikasi perangkat keras bandwidth jaringan dan (Gbps/core), dan kinerja CPU secara keseluruhan (CPU/core).

Tip

Untuk diskusi tentang pelacakan metrik, termasuk cara mengekstrak metrik dari cloud Anda, lihat OpenStack Operations Guide.

Menambahkan node pengontrol cloud

Anda dapat memfasilitasi ekspansi horisontal cloud Anda dengan menambahkan node. Menambahkan node komputasi sangat mudah karena mudah diambil oleh instalasi yang ada. Namun, Anda harus mempertimbangkan beberapa poin penting ketika Anda mendesain cluster Anda menjadi sangat tersedia.

Node pengontrol cloud menjalankan beberapa layanan berbeda. Anda dapat menginstal layanan yang berkomunikasi hanya menggunakan antrian pesan secara internal— nova-scheduler dan `` nova-console`` pada server baru untuk ekspansi. Namun, bagian integral lainnya membutuhkan perawatan lebih.

Anda harus memuat keseimbangan layanan yang menghadap pengguna seperti dasbor, nova-api, atau proksi Object Storage. Gunakan metode penyeimbangan beban HTTP standar (round robin DNS, penyeimbang beban perangkat keras, atau perangkat lunak seperti Pound atau HAProxy). Satu peringatan dengan dashboard adalah proksi VNC, yang menggunakan protokol WebSocket — sesuatu yang mungkin dihadapi oleh penyeimbang beban L7. Lihat juga Horizon session storage.

Anda dapat mengkonfigurasi beberapa layanan, seperti nova-api dan glance-api, untuk menggunakan beberapa proses dengan mengubah tanda pada file konfigurasi mereka yang memungkinkan mereka untuk berbagi kerja antara beberapa core pada satu mesin.

Tip

Beberapa opsi tersedia untuk penyeimbangan beban MySQL, dan AMQP broker yang didukung memiliki dukungan pengelompokan bawaan. Informasi tentang cara mengkonfigurasi ini dan banyak layanan lainnya dapat ditemukan di Internet Operations Guide.

Memisahkan cloud Anda

Memisahkan cloud Anda diperlukan ketika pengguna memerlukan wilayah yang berbeda untuk pertimbangan hukum untuk penyimpanan data, redundansi di seluruh jalur gangguan gempa bumi, atau untuk panggilan API latensi rendah. Ini dapat dipisahkan oleh cells, regions, availability zones, atau host aggregates.

Setiap metode menyediakan fungsionalitas yang berbeda dan dapat dibagi menjadi dua kelompok:

• Sel dan wilayah, yang memisahkan seluruh cloud dan menghasilkan menjalankan penyebaran Compute yang terpisah.

• Availability zones dan host agregat, yang hanya membagi satu penyebaran Compute.

Table. Metode segregasi OpenStack memberikan tampilan perbandingan setiap metode pemisahan yang saat ini disediakan oleh OpenStack Compute.

Table. Metode segregasi OpenStack

	Cells	Regions	Availability zones	Host aggregates
Use	Pecahan dan skala penyebaran penyebaran sambil mempertahankan satu API endpoint.	Wilayah diskrit dengan endpoint API terpisah dan tidak ada koordinasi antar wilayah.	Pemisahan logis dalam penyebaran nova Anda untuk isolasi fisik atau redundansi.	Untuk menjadwalkan sekelompok host dengan fitur-fitur umum.
Example	Cloud dengan banyak situs tempat Anda dapat menjadwalkan VM "anywhere" atau di situs tertentu.	Cloud dengan banyak situs, tempat Anda menjadwalkan VM ke situs tertentu dan Anda menginginkan infrastruktur bersama.	Single-site cloud dengan peralatan yang diumpankan oleh catu daya terpisah.	Penjadwalan ke host dengan dukungan perangkat keras tepercaya.
Overhead	Setiap Cell berisi instances layanan dengan fungsionalitas yang tumpang tindih.	Endpoint API yang berbeda untuk setiap wilayah. Setiap wilayah memiliki instalasi nova lengkap.	Konfigurasi berubah menjadi nova.conf.	Konfigurasi berubah menjadi nova.conf.
Shared services	Keystone, nova-api	Keystone	Keystone, Semua layanan nova	Keystone, Semua layanan nova

Sel dan daerah

OpenStack Compute Cells <https://docs.openstack.org/nova/latest/user/cells.html> _ dirancang untuk memungkinkan menjalankan cloud secara terdistribusi tanpa harus menggunakan teknologi yang lebih rumit, atau invasif ke instalasi nova yang ada. Host di cloud dipartisi ke dalam grup yang disebut Cells. Cells dikonfigurasikan dalam tree. Cell tingkat atas ("API cell") memiliki host yang menjalankan layanan nova-api, tetapi tidak ada layanan nova-compute. Nova-compute berjalan di child Cell. Setiap Cell memiliki antrian pesan dan layanan database sendiri.

Ini memungkinkan server API tunggal digunakan untuk mengontrol akses ke beberapa instalasi komputasi dengan penggunaan beberapa Cells. Lihat Nova Cells V2 Layout untuk dokumentasi lebih lanjut.

Tidak seperti memiliki satu endpoint API, kawasan memiliki endpoint API terpisah per pemasangan, memungkinkan pemisahan yang lebih terpisah. Pengguna yang ingin menjalankan instance di situs harus secara eksplisit memilih suatu wilayah. Namun, kompleksitas tambahan menjalankan layanan baru tidak diperlukan.

Dasbor OpenStack (horizon) dapat dikonfigurasi untuk menggunakan banyak wilayah. Ini dapat dikonfigurasi melalui parameter AVAILABLE_REGIONS.

Zona ketersediaan dan agregat host

Anda dapat menggunakan zona ketersediaan, agregat host, atau keduanya untuk mempartisi penyebaran nova. Kedua metode dikonfigurasikan dan diimplementasikan dengan cara yang serupa.

Zona ketersediaan

Ini memungkinkan Anda untuk mengatur host komputasi OpenStack ke dalam grup logis dan menyediakan bentuk isolasi fisik dan redundansi dari zona ketersediaan lainnya, seperti dengan menggunakan catu daya atau peralatan jaringan yang terpisah.

Anda menentukan zona ketersediaan tempat host komputasi tertentu berada secara lokal di setiap server. Zona ketersediaan biasanya digunakan untuk mengidentifikasi satu set server yang memiliki atribut umum. Misalnya, jika beberapa rak di pusat data Anda berada di sumber daya yang terpisah, Anda dapat menempatkan server di rak tersebut di zona ketersediaannya sendiri. Zona ketersediaan juga dapat membantu memisahkan berbagai kelas perangkat keras.

Ketika pengguna menyediakan sumber daya, mereka dapat menentukan dari zona ketersediaan mana mereka ingin instance mereka dibangun. Hal ini memungkinkan konsumen cloud untuk memastikan bahwa sumber daya aplikasi mereka tersebar di berbagai mesin yang berbeda untuk mencapai ketersediaan tinggi jika terjadi kegagalan perangkat keras.

Zona agregat host

Ini memungkinkan Anda untuk mempartisi penyebaran OpenStack Compute ke dalam grup logis untuk penyeimbangan beban dan distribusi instance. Anda dapat menggunakan agregat host untuk lebih lanjut mempartisi zona ketersediaan. Misalnya, Anda dapat menggunakan agregat host untuk mempartisi zona ketersediaan ke dalam grup host yang berbagi sumber daya bersama, seperti penyimpanan dan jaringan, atau memiliki properti khusus, seperti perangkat keras komputasi tepercaya.

Penggunaan agregat host yang umum adalah untuk memberikan informasi untuk digunakan dengan nova-scheduler. Misalnya, Anda dapat menggunakan agregat host untuk mengelompokkan serangkaian host yang berbagi flavor atau image tertentu.

Kasus umum untuk ini adalah pengaturan pasangan key-value dalam metadata agregat dan pasangan key-value yang cocok dalam metadata extra_specs flavor. AggregateInstanceExtraSpecsFilter di penjadwal filter akan memastikan bahwa instance hanya dijadwalkan pada host dalam agregat yang menentukan key yang sama dengan value yang sama.

Penggunaan lanjutan dari konsep umum ini memungkinkan jenis flavor berbeda untuk dijalankan dengan rasio alokasi CPU dan RAM yang berbeda sehingga beban komputasi intensitas tinggi dan pengembangan dan sistem pengujian intensitas rendah dapat berbagi cloud yang sama tanpa penurunan (starving) sistem penggunaan tinggi ataupun pemborosan. sumber daya pada sistem pemanfaatan rendah. Ini bekerja dengan mengatur metadata di agregat host Anda dan mencocokkan extra_specs dalam jenis flavor Anda.

Langkah pertama adalah mengatur kunci metadata agregat cpu_allocation_ratio dan ram_allocation_ratio ke nilai floating-point. Penjadwal filter AggregateCoreFilter dan AggregateRamFilter akan menggunakan nilai-nilai itu daripada standar global di nova.conf saat menjadwalkan host di agregat. Berhati-hatilah saat menggunakan fitur ini, karena setiap host dapat terdiri dari beberapa agregat, tetapi harus hanya memiliki satu rasio alokasi untuk setiap sumber daya. Terserah Anda untuk menghindari menempatkan host dalam beberapa agregat yang menentukan nilai yang berbeda untuk sumber daya yang sama.

Ini adalah bagian pertama dari persamaan. Untuk mendapatkan jenis flavor yang dijamin dengan rasio tertentu, Anda harus mengatur extra_specs dalam jenis flavor ke pasangan nilai kunci yang ingin Anda cocokkan dalam agregat. Misalnya, jika Anda mendefinisikan extra_specs cpu_allocation_ratio ke "1.0", maka instance jenis itu akan berjalan dalam agregat hanya di mana kunci metadata cpu_allocation_ratio juga didefinisikan sebagai "1.0." Dalam praktiknya, lebih baik untuk menentukan pasangan nilai kunci tambahan dalam metadata agregat untuk dicocokkan daripada mencocokkan secara langsung pada cpu_allocation_ratio atau core_allocation_ratio. Ini memungkinkan abstraksi yang lebih baik. Misalnya, dengan mendefinisikan kunci overcommit dan menetapkan nilai "high," "medium," atau "low," Anda kemudian dapat menyetel rasio alokasi numerik dalam agregat tanpa juga perlu mengubah semua jenis flavor yang terkait ke mereka.

Catatan

Sebelumnya, semua layanan memiliki zona ketersediaan. Saat ini, hanya layanan nova-compute yang memiliki zona ketersediaannya sendiri. Layanan seperti nova-scheduler, nova-network, dan nova-conductor selalu membentang semua zona ketersediaan.

Ketika Anda menjalankan salah satu dari operasi berikut, layanan muncul di zona ketersediaan internal mereka sendiri (CONF.internal_service_avilities_zone):

• openstack host list (os-hosts)

• euca-describe-availability-zones verbose

• openstack compute service list

Zona ketersediaan internal disembunyikan di euca-description-availability_zones (nonverbose).

CONF.node_available_zone telah diubah namanya menjadi CONF.default_available_zone dan hanya digunakan oleh layanan nova-api dan nova-scheduler.

CONF.node_avilities_zone masih berfungsi tetapi sudah usang.

Perangkat keras yang dapat diskalakan

Sementara beberapa sumber daya sudah ada untuk membantu dalam menggunakan dan menginstal OpenStack, sangat penting untuk memastikan bahwa Anda memiliki penyebaran yang direncanakan sebelumnya. Panduan ini mengandaikan bahwa Anda telah menyiapkan rak untuk cloud OpenStack tetapi juga menawarkan saran kapan dan apa untuk skala.

Pengadaan Perangkat Keras

"The Cloud" telah dideskripsikan sebagai lingkungan yang tidak stabil di mana server dapat dibuat dan diakhiri sesuka hati. Meskipun ini mungkin benar, itu tidak berarti bahwa server Anda harus tidak stabil. Memastikan perangkat keras cloud Anda stabil dan terkonfigurasi dengan benar berarti bahwa lingkungan cloud Anda tetap aktif dan berjalan.

OpenStack dapat digunakan pada perangkat keras apa pun yang didukung oleh distribusi Linux yang kompatibel dengan OpenStack.

Perangkat keras tidak harus konsisten, tetapi setidaknya harus memiliki jenis CPU yang sama untuk mendukung migrasi instance.

Perangkat keras khas yang direkomendasikan untuk digunakan dengan OpenStack adalah penawaran value-for-money standar yang disediakan oleh sebagian besar vendor perangkat keras. Harus mudah untuk membagi pengadaan Anda ke dalam blok bangunan seperti "compute," "object storage," dan "cloud controller," dan meminta sebanyak mungkin yang Anda butuhkan. Atau, setiap server yang Anda miliki yang memenuhi persyaratan kinerja dan teknologi virtualisasi cenderung mendukung OpenStack.

Perencanaan Kapasitas

OpenStack dirancang untuk meningkatkan ukuran secara langsung. Mempertimbangkan pertimbangan yang disebutkan sebelumnya, terutama pada ukuran pengontrol cloud, harus dimungkinkan untuk mendapatkan node komputasi atau penyimpanan objek tambahan sesuai kebutuhan. Node baru tidak perlu spesifikasi atau vendor yang sama dengan node yang ada.

Untuk komputasi node, nova-scheduler akan mengatur perbedaan ukuran dengan core count dan RAM. Namun, Anda harus mempertimbangkan bahwa pengalaman pengguna berubah dengan kecepatan CPU yang berbeda. Saat menambahkan node penyimpanan objek, :term: weight harus ditentukan yang mencerminkan :term:` capability ` node.

Memantau penggunaan sumber daya dan pertumbuhan pengguna akan memungkinkan Anda mengetahui kapan harus membeli. Bab Logging and Monitoring dalam Operations Guide merinci beberapa metrik yang berguna.

Burn-in Testing

Peluang kegagalan untuk perangkat keras server menjadi tinggi pada awal dan akhir masa pakainya. Akibatnya, berurusan dengan kegagalan perangkat keras saat dalam produksi dapat dihindari dengan pengujian burn-in yang tepat untuk mencoba memicu kegagalan tahap awal. Prinsip umum adalah menekankan perangkat keras hingga batasnya. Contoh tes burn-in termasuk menjalankan benchmark CPU atau disk selama beberapa hari.