Dalam artikel ini, Igor Kotenko, Kepala Arsitek Neoflex, membagikan pengalamannya dalam menerapkan platform containerization pada infrastruktur perusahaan.
Alasan mengapa perusahaan biasanya memilih solusi on-premise seringkali non-teknologi dan seringkali terkait dengan pendanaan. Seseorang sedang mencoba untuk mengurangi biaya operasi (membayar untuk cloud eksternal) untuk memanfaatkan perusahaan (membeli server mereka sendiri), seseorang sudah memiliki sumber daya perangkat keras yang solid dan ingin menggunakannya dalam arsitektur layanan mikro.
Sebelum beralih ke detail implementasi, mari kita beralih ke persyaratan.
Istilah "awan" dianggap sangat padat. Merupakan kebiasaan untuk membedakan berbagai jenis solusi cloud:
- Infrastructure as a Service (IAAS) - perangkat keras (biasanya virtual);
- Software as a Service (SAAS), misalnya, DBAS - database sebagai layanan;
- Platform sebagai Layanan (PAAS);
- Aplikasi sebagai Layanan (AAAS).
Pada saat yang sama, tidak ada yang mencegah lapisan tersebut didasarkan satu sama lain. Jelas, akan ada infrastruktur di bawah platform atau perangkat lunak.
Ada beberapa kebingungan tentang istilah "awan pribadi". Terkadang ini disebut cloud on-premise, terkadang diterapkan pada infrastruktur yang disewa dengan isolasi lengkap dari segmen jaringan Anda. Bahkan ada penyebutan mesin virtual dengan memori dan disk terenkripsi, sementara memory dump tidak akan memberi penyedia akses ke informasi Anda. Pada artikel ini, kita akan membahas solusi yang digunakan di rumah - di lokasi.
Saat memperkenalkan awan pribadi, diharapkan sama dengan awan publik, hanya saja lebih murah, lebih aman, dan lebih andal. Oleh karena itu, banyak orang berpikir bahwa awan pribadi lebih baik secara apriori. Seringkali, para ahli hanya menerapkan versi Kubernetes atau Openhift yang dipilih dan percaya bahwa di sinilah pekerjaan mereka diselesaikan.
Apa yang diharapkan perusahaan saat menerapkan cloud on-premise:
- Biaya sumber daya rendah. Karena Anda hanya membayar apa yang Anda gunakan.
- Kemampuan untuk menambah dan mengembalikan sumber daya secepat mungkin.
- Toleransi kesalahan. Server macet, yang lain diberikan secara otomatis.
- Biaya dukungan rendah.
Bagaimana ini dicapai di cloud publik?
Biasanya, karena otomatisasi proses, skala ekonomi (lebih murah dalam jumlah besar) dan berbagi sumber daya antara konsumen yang berbeda.
Mari kita lihat janji-janji ini dalam konteks cloud pribadi.
1. Biaya sumber daya yang rendah dibandingkan dengan infrastruktur konvensional.
Nyatanya, tidak demikian. Perangkat lunak yang sama diterapkan pada mesin yang sama, tetapi dalam wadah. Sebaliknya, menurut pengalaman kami, lebih banyak sumber daya terbuang percuma.
2. Kemampuan untuk menambah dan mengurangi sumber daya dengan sangat cepat.
Tidak. Untuk memperluas, Anda perlu menyimpan cadangan lisensi perangkat keras dan perangkat lunak tetap menganggur, atau pertama-tama membuang sesuatu yang tidak perlu. Anda dapat mengambil sumber daya agar tidak digunakan, tetapi kemudian akan menganggur.
3. Toleransi kesalahan.
Ya, tapi ada banyak nuansa. Katakanlah server sedang down. Di mana saya bisa mendapatkan yang lain? Bagaimana cara cepat menyebarkan dan menambahkannya ke cluster? Jika Anda bukan Amazon, maka Anda tidak memiliki persediaan sumber daya yang tidak terbatas.
4. Biaya dukungan yang rendah.
Kami telah menambahkan setidaknya satu lapisan lagi (platform kontainerisasi), beberapa sistem baru. Kami membutuhkan spesialis dengan kompetensi baru. Dari mana simpanan itu berasal?
Mari kita bahas masalah ini lebih detail. Penting untuk diingat bahwa cloud pribadi harus hidup berdampingan dengan sistem lama yang ada. Organisasi dipaksa untuk memelihara infrastruktur sistem yang ada secara paralel, mengatur lingkungan TI hybrid.
Secara alami, 99% sistem tidak dibangun dari awal. Biasanya, bahkan sebelum implementasi solusi PAAS, terdapat serangkaian proses dan otomatisasi untuk mendukung infrastruktur lama. Proses DevOps, perencanaan dan kepemilikan sumber daya, pemantauan, pembaruan perangkat lunak, keamanan - semua masalah ini harus disetujui dan diubah selama penerapan cloud pribadi.
Bagaimana proses DevOps berubah
Biasanya, sebelum menerapkan PAAS Anda sendiri, pendekatan untuk membangun DevOps didasarkan pada penggunaan sistem otomasi konfigurasi seperti Ansible atau Chef. Mereka memungkinkan Anda untuk mengotomatiskan hampir semua proses TI rutin, sering kali menggunakan pustaka skrip yang sudah jadi. Namun, platform kontainerisasi mempromosikan pendekatan alternatif - "infrastruktur yang tidak dapat diubah". Intinya bukan untuk mengubah sistem yang ada, tetapi untuk mengambil gambar virtual yang sudah jadi dari sistem dengan pengaturan baru dan mengganti gambar lama dengan yang baru. Pendekatan baru tidak meniadakan yang lama, tetapi memaksa otomatisasi konfigurasi ke dalam lapisan infrastruktur. Tentu saja, sistem lama membutuhkan pendekatan lama.
Mari kita bicara tentang lapisan infrastruktur
Standar de facto dalam TI adalah penggunaan infrastruktur virtual. Seperti yang ditunjukkan oleh praktik, opsi paling umum adalah menggunakan vSphere. Ada banyak alasan untuk ini, tetapi ada juga konsekuensinya. Dalam praktik kami, masalah yang sering terjadi dengan kelebihan permintaan dalam hal sumber daya (upaya untuk menjahit tujuh tutup dari satu kulit) diperburuk oleh kurangnya kontrol dan pengaruh yang hampir sepenuhnya pada proses ini dari mereka yang bertanggung jawab atas kinerja solusi. Batasan area tanggung jawab di divisi perusahaan, formalisasi prosedur permintaan sumber daya dan tujuan berbeda dari manajemen divisi menyebabkan masalah di lingkungan produk dan pengujian beban yang tidak konsisten. Pada titik tertentu, departemen pengembangan kami bahkan membuat alat pengukuran kinerja inti virtual,untuk segera mendiagnosis kekurangan sumber daya perangkat keras.
Jelas bahwa upaya untuk menempatkan platform containerization pada infrastruktur seperti itu akan membawa warna baru pada kekacauan yang ada.
Pertanyaan apakah platform containerization on-premise memerlukan infrastruktur virtual atau lebih baik meletakkannya di bare-metal (di server besi) telah dibahas sejak lama dan cukup luas. Artikel yang dilobi oleh produsen sistem virtualisasi berpendapat bahwa secara praktis tidak ada kerugian kinerja, dan manfaatnya terlalu besar. Di sisi lain, ada hasil tes independen yang mengatakan kerugian kinerja sekitar 10%. Jangan lupa tentang biaya lisensi vSphere. Misalnya, memasang versi gratis Kubernetes pada perangkat keras yang tidak mahal hanya untuk menghemat uang dan membayar vSphere? Keputusan kontroversial.
Perlu disebutkan solusi virtualisasi infrastruktur open source, misalnya, Open Stack. Secara keseluruhan, dia dipandang sebagai solusi yang membutuhkan investasi signifikan dalam tim. Ada statistik di jaringan yang menurut ukuran tim dukungan Open Stack adalah 20 hingga 60 orang. Dan ini terpisah dari dukungan platform containerization! Ada beberapa spesialis seperti itu di pasaran, yang meningkatkan biaya mereka. Investasi semacam itu biasanya hanya membuahkan hasil pada volume sumber daya yang sangat besar.
Penting untuk mempertimbangkan keberadaan spesialis dengan kompetensi unik di perusahaan. Sayangnya, penginstalan Kubernetes tanpa logam, terlepas dari manfaat transparansi dan biaya lisensi yang lebih rendah, sering kali terhambat, misalnya, kurangnya alat otomatisasi penginstalan yang tepat. Kami berharap masa depan termasuk dalam pendekatan ini.
Aspek lain yang mempengaruhi pilihan antara instalasi virtual dan bare-metal adalah pengaturan server besi.
Biasanya, organisasi membeli server untuk tujuan tertentu. Anda dapat menyewa server di pusat data (dari apa yang mereka tawarkan), Anda dapat menstandarisasi dan menyatukan nomenklatur (menyederhanakan redundansi komponen), Anda dapat menghemat perangkat keras (banyak server murah), Anda dapat menghemat ruang rak. Pendekatan yang berbeda di organisasi yang berbeda. Secara umum, ini adalah server yang kuat dengan sejumlah besar inti dan memori, atau volume yang relatif kecil, atau gado-gado prefabrikasi. Tapi, jangan lupakan kebutuhan sistem legacy. Pada titik ini, kita sekali lagi menemukan kontradiksi dalam konsep. Ideologi Kubernetes adalah banyak perangkat keras yang murah dan kesiapan untuk kegagalannya. Server jatuh - tidak masalah, layanan Anda telah dipindahkan ke yang lain. Data dipecah (digandakan), tidak terikat ke penampung. Ideologi warisan - redundansi di tingkat perangkat keras. Array RAID,rak disk, beberapa catu daya di server, hot swap. Fokus pada keandalan maksimum. Bisa jadi sangat mahal untuk mempertaruhkan infrastruktur Kubernetes semacam itu.
, …
Jika sebuah perusahaan memiliki server berkinerja tinggi dengan banyak inti, mungkin perlu untuk membaginya di antara konsumen yang berbeda. Di sini Anda tidak akan dapat melakukannya tanpa sistem virtualisasi. Pada saat yang sama, perlu untuk mempertimbangkan kemungkinan kegagalan server atau penghentian untuk pemeliharaan. Perhitungannya sederhana: jika Anda memiliki dua server, jika salah satunya gagal, Anda memerlukan 50% cadangan daya pada masing-masing; jika - 4 server, jika salah satu gagal, Anda perlu cadangan 25%. Pada pandangan pertama, semuanya sederhana - Anda memerlukan server dalam jumlah tak terbatas, maka kegagalan salah satunya tidak akan memengaruhi kapasitas total dan Anda tidak perlu memesan apa pun. Sayangnya, ukuran resource dari satu host tidak dapat sangat dikurangi. Minimal, ini harus mengakomodasi semua komponen terkait, yang oleh terminologi Kubernetes disebut sebagai "pod". Dan, tentu saja, saat masuk ke server yang lebih kecil,biaya overhead untuk layanan platform itu sendiri meningkat.
Untuk tujuan praktis, diinginkan untuk menyatukan parameter host untuk platform. Dalam contoh yang mendekati kehidupan, ada 2 pusat data (dukungan untuk skenario DR berarti setidaknya 50% cadangan sumber daya dalam hal kapasitas). Selanjutnya, kebutuhan organisasi akan resource platform containerization ditentukan dan kemungkinan menempatkannya di bare-metal standar, atau host virtual. Rekomendasi Kubernetes - tidak lebih dari 110 pod per node.
Dengan demikian, untuk menentukan ukuran node, Anda perlu mempertimbangkan hal-hal berikut:
- Diinginkan untuk membuat simpul-simpulnya sama;
- Node harus sesuai dengan perangkat keras Anda (untuk mesin virtual - kelipatan, N virtual untuk satu perangkat keras);
- Jika satu node gagal (untuk versi dengan infrastruktur virtual - satu server besi), Anda harus memiliki cukup sumber daya pada node yang tersisa untuk memindahkan pod ke sana;
- Tidak boleh ada terlalu banyak (> 110) pod pada satu node;
- Hal lain dianggap sama, diinginkan untuk membuat node lebih besar.
Jenis fitur ini harus dipertimbangkan dalam setiap aspek arsitektur.
Logging terpusat - bagaimana memilih dari beberapa opsi?
Pemantauan - mungkin sistem pemantauan Anda yang ada tidak akan berfungsi, menyimpan dua atau bermigrasi ke yang baru?
Pembaruan platform ke versi baru - secara teratur atau hanya jika benar-benar diperlukan?
Fault Tolerant Balancing Antara Dua Data Center - Bagaimana?
Arsitektur keamanan, interaksi dengan sistem lama - ada perbedaan dari awan publik. Sangat mungkin untuk merekomendasikan membangun sistem sehingga ada kemungkinan migrasi ke cloud publik, tetapi ini akan mempersulit solusi.
Ada sedikit perbedaan dalam perencanaan, alokasi dan kepemilikan sumber daya untuk awan publik dan pribadi. Perbedaan utamanya adalah jumlah sumber daya yang terbatas. Jika di cloud publik dimungkinkan kapan saja untuk mengambil sumber daya tambahan yang diperlukan, misalnya, untuk pengujian beban, maka on-premise harus merencanakan dengan hati-hati urutan penggunaannya. Ini berarti Anda mungkin memiliki peluncuran malam hari dan, karenanya, pekerjaan karyawan dari lini ke-2 dan ke-3 akan meningkat pada jam-jam yang tidak tepat. Tidak ada yang baru bagi mereka yang sendirian, kecuali rasa pahit dari kekecewaan atas keajaiban menunggu adopsi cloud pribadi.
"Kader memutuskan segalanya"
Saat merencanakan implementasi platform containerization on-premise, pertama-tama, dibutuhkan spesialis dengan kompetensi unik. Di pasar tenaga kerja saat ini, mereka jelas tidak cukup. Selain itu, tanpa pengalaman penerapan semacam itu, sulit bahkan untuk membuat daftar semua spesialis yang diperlukan.
Misalnya, agar platform berfungsi, Anda perlu memilih dan menginstal sistem penyimpanan. Sistem mana pun yang Anda pilih (CEPH atau Portworx), itu akan menjadi penting untuk platform. Semua orang tahu bahwa dibutuhkan seorang administrator untuk memelihara database. Demikian pula, sistem penyimpanan data membutuhkan spesialis terpisah. Sayangnya, tidak ada yang memikirkan hal ini sebelum menerapkan sistem! Perhatikan bahwa perbedaan antara administrator untuk produk yang berbeda adalah signifikan - sebanding dengan perbedaan antara Oracle DBA dan MS SQL DBA. Anda akan membutuhkan setidaknya dua orang untuk setiap peran: karyawan pergi berlibur, sakit, dan bahkan, amit-amit, berhenti. Begitu seterusnya untuk setiap kompetensi, dan daftar kompetensi yang diperlukan untuk mendukung solusi sangat mengesankan.
Saya ingin segera memperingatkan terhadap upaya untuk melintasi semua kompetensi di beberapa tentara universal. Biaya, kelangkaan, dan risiko kerugiannya melebihi semua batas yang wajar.
Sekali lagi, pemeliharaan cloud adalah proses yang kompleks. Perusahaan cloud tidak memakan roti mereka dengan sia-sia: di sana, di balik kabut mendung, ada banyak teknologi dan tenaga kerja yang diinvestasikan.
Tentu saja, penggunaan layanan konsultasi dapat mempercepat implementasi platform secara signifikan. Mitra yang berpengalaman akan membantu Anda menghindari banyak kesalahan, menetapkan proses, dan melatih tim Anda. Namun, jika Anda menyelenggarakan layanan penting untuk bisnis Anda di platform, sama pentingnya untuk memberikan dukungan dan pengembangan yang berkualitas. Selain itu, saat ini, semua sistem yang ada di pasar sedang berkembang secara aktif, teknologi baru muncul, versi baru platform mungkin memerlukan migrasi proses yang kompleks dan pengujian serius sebelum memperbarui. Tim pendukung yang kuat diperlukan untuk memastikan pengoperasian sistem yang andal. Dan Anda akan membutuhkan tim seperti itu secara berkelanjutan.
Kapan Anda harus mempertimbangkan untuk menerapkan platform containerization di lokasi?
Pertama-tama, perlu untuk menilai rasio antara investasi dan pengembalian, volume biaya untuk perangkat keras dan karyawan. Pasti ada alasan bagus untuk tidak bisa hidup di cloud publik, atau kebutuhan sumber daya yang sangat serius. Artinya, jika sekitar 100 Core cukup untuk sebuah organisasi dan Anda belum siap untuk memperluas tim dukungan ke lusinan orang, kemungkinan besar Anda harus fokus pada cloud publik, atau pada konfigurasi sederhana dengan server aplikasi. Ada ukuran tim minimum yang diperlukan untuk mendukung platform dan biayanya mungkin tidak terbayar. Namun, dengan sumber daya penskalaan dan otomatisasi yang kompeten dari semua proses, manfaat dari solusi pribadi bisa sangat signifikan. Ratusan node dapat dipertahankan dengan banyak perintah yang sama.
Kriteria seleksi lainnya adalah variabilitas kebutuhan sumber daya komputasi. Jika proses bisnis perusahaan menghasilkan sumber daya yang lebih atau kurang, lebih menguntungkan untuk mengembangkan infrastrukturnya sendiri. Jika Anda perlu menggunakan kapasitas besar, tetapi jarang, pertimbangkan cloud publik atau hybrid.
Bagaimanapun, ketika memilih solusi di lokasi, saksikan pekerjaan yang serius dan sistematis, bersiaplah untuk berinvestasi dalam tim. Beranjak dari yang sederhana ke yang kompleks. Perhatikan waktu penerapan, dan berhati-hatilah saat meningkatkan ke versi baru platform. Gunakan pengalaman yang didapat dari kesalahan orang lain, bukan kesalahan Anda.
Terima kasih telah membaca artikel ini, semoga informasinya bermanfaat.