⛸️ 🤲🏻 ☹️ Apa yang harus disimpan di cloud 🔇 ▪️ 💱

Awan nyaman dengan fleksibilitasnya. Kami membutuhkan cluster komputasi yang kuat selama delapan jam: disewa dalam tiga klik, menyelesaikan tugas dan mematikan mobil. Sayangnya, banyak yang hanya salah memahami ideologi sumber daya cloud dan sering kecewa ketika mereka melihat akun di akhir bulan.

Untuk mengoptimalkan biaya, Anda harus mulai dengan mengumpulkan statistik yang baik. Saya akan mencoba menjelaskan secara singkat alat yang tepat untuk ini.

Prinsip utama menabung adalah mematikan semua yang tidak perlu dan meminimalkan cadangan sebanyak mungkin. Menyapih untuk berpikir dalam paradigma server lokal dalam infrastruktur perusahaan. Jika Anda dapat mengotomatiskan ekspansi dan penutupan sumber daya cloud tergantung pada beban - bahkan lebih baik.

Pertimbangkan situasi di mana tarif tetap lebih menguntungkan, dan kapan - konsep pay-as-you-go (PAYG). Plus, pertimbangkan apa yang bisa Anda matikan kelebihannya, dan di mana sumber daya paling sering terbuang. Mari kita lihat jenis sumber daya utama: CPU, RAM, disk virtual, jaringan, dan cadangan.

Kami mengumpulkan informasi

Sebelum Anda melakukan tindakan pengoptimalan, Anda harus terlebih dahulu memahami bagaimana mesin Anda dimuat. Oleh karena itu, paling tepat untuk memulai dengan sistem pemantauan untuk memahami secara akurat sifat beban. Selain itu, beban harus dianalisis pada skala yang berbeda. Data rata-rata untuk bulan ini akan berguna untuk memahami tingkat pemesanan atau kekurangan sumber daya secara umum. Selain itu, Anda dapat memperkirakan tanggal perkiraan saat kapasitas saat ini akan berhenti menjadi cukup jika beban bertambah secara bertahap. Data selama beberapa hari akan dapat menunjukkan fluktuasi diurnal, biasanya terkait dengan siklus hidup zona waktu, dan semburan tunggal yang tajam ketika sumber daya terbatas.

Cara memonitor

Ada sejumlah besar pengumpulan informasi dan sistem visualisasi untuk dipilih, tetapi saya ingin menarik perhatian pada yang utama:

Zabbix — . , .
Kibana — ELK. , , .
Grafana — , . , .
. , .

Cloud itu sendiri dirancang untuk menghemat uang, tetapi Anda juga dapat mengoptimalkan biaya dengan mengonsumsi sumber daya cloud dengan benar. Perkirakan pemuatan seragam mesin Anda. Jika mesin virtual dimuat secara stabil, maka semuanya baik-baik saja, dan tarif dengan batas tetap dan cadangan daya kecil akan sangat menguntungkan.

Selama beban puncak, hanya satu inti yang terlibat. Anda dapat menghemat uang dan tidak mengambil dua.

Anda dapat mengambil dua inti bukannya empat tanpa kehilangan kinerja.

Jika lebih dari 10% waktu VM menganggur, maka Anda perlu mencoba mengandalkan model PAYG. Hanya dengan demikian mesin harus dimatikan saat tidak digunakan. Misalnya, sekali sehari, sebuah simpul menyala, mengkompilasi proyek dan mematikannya lagi.

Semua core dimuat secara merata. Kemungkinan besar, akan menguntungkan untuk mengambil tarif dengan pembayaran tetap.

Biasanya, taktik optimasi finansial terlihat seperti ini: Anda membagi elemen infrastruktur Anda menjadi yang stabil dengan konsumsi dan yang tidak stabil dengan beban puncak. Kami mencoba mentransfer elemen dengan konsumsi konstan ke tarif tetap, dan yang tidak stabil ke PAYG, agar dapat memuluskan semburan tunggal dengan lancar dengan murah.

Kami melakukan hal yang sama dengan berbagai mesin uji dan percobaan. Paling sering, lebih menguntungkan untuk membayar mereka berdasarkan sumber daya yang dikonsumsi, daripada dengan tarif tetap. Jika Anda menemukan mobil yang mengonsumsi 1% daya, matikan dan transfer ke PAYG.

Anda perlu memahami bahwa di cloud Anda tidak membayar untuk beban pada prosesor, tetapi untuk fakta menggunakan core. Jika Anda menggunakan paket tarif PAYG dan Anda tidak memerlukan VM saat ini, misalnya, Anda telah melakukan tes yang diperlukan dan tidak menggunakannya lagi, maka lebih logis untuk mematikannya dan dengan demikian menghemat biaya memori virtual dan prosesor.

Beberapa klien menggunakan API Direktur vCloud untuk menghidupkan dan mematikan VM sesuai jadwal untuk menghemat lebih banyak lagi pada sumber daya yang dikonsumsi. Pendekatan yang sangat baik adalah menggunakan orkestrasi untuk mengontrol cloud, menghidupkan dan mematikan node ketika beban berubah.

Pada saat yang sama, Anda harus membayar disk virtual. Jika Anda tidak lagi membutuhkan VM, maka lebih baik untuk menghapusnya. Atau, jika Anda menggunakannya sangat jarang, maka untuk sementara, saat tidak aktif, transfer ke penyimpanan yang lebih murah. Anda juga dapat menyimpan di disk virtual jika Anda menggunakan node setiap kali dari template yang sudah jadi, daripada mematikan yang sudah selesai. Dan simpan templat sudah dalam penyimpanan murah.

RAM

Anda seharusnya tidak mengalokasikan lebih banyak memori ke VM daripada yang diperlukan. Sangat sering, pengguna cloud mengkonfigurasi VM secara empiris: "Ya, tentang sebanyak memori yang perlu dibuang dan begitu banyak core." Pada saat yang sama, RAMlah yang, sebagai suatu peraturan, adalah sumber daya paling mahal di cloud.

Menggunakan rencana tarif PAYG, masuk akal untuk mengkonfigurasi VM sehingga secara optimal menggunakan sumber daya yang dialokasikan untuknya, memiliki margin dalam kinerja untuk beban puncak. Pada saat yang sama, cadangan tidak boleh x4 atau x10 dari konsumsi rata-rata aplikasi Anda: itu hanya irasional mahal. Tentu saja, batas selalu ditentukan secara individual untuk setiap tugas, tetapi paling sering Anda harus berusaha untuk memastikan bahwa stok tidak melebihi 25%.

Disk virtual

Salah satu sumber daya penting adalah disk virtual. Ada beberapa jenis disk virtual yang berbeda dalam kecepatan dan harga. Semakin cepat drive, semakin mahal yang diharapkan. Oleh karena itu, penghematan pada parameter ini harus dimulai dengan analisis dan pemisahan data menjadi "dingin" dan "panas".

Opsi yang salah. Kebijakan alokasi VM dikonfigurasi sehingga swap, konfigurasi, dan disk VM akan ditempatkan pada disk mahal, kecuali jika Anda secara eksplisit menentukan sebaliknya.

VM secara bersamaan dapat menggunakan berbagai jenis disk yang dapat ditempatkan pada penyimpanan cepat dan lambat. Dengan demikian, jika Anda menyimpan beberapa jenis arsip data atau log, masuk akal untuk meletakkannya di disk yang lambat. Database sangat penting untuk IOPS, jadi kami mengirimkannya ke repositori cepat.

Opsi yang benar. Setiap tipe data memiliki kecepatan disk sendiri.

Sekarang kita perlu memecahkan pertanyaan di mana disk untuk menempatkan VM itu sendiri. Platform vloud Director memiliki fitur: ia mencadangkan ruang disk untuk RAM VM pada saat peluncurannya. Dalam hal ini, Anda pra-pilih jenis penyimpanan. OS itu sendiri tidak terlalu penting untuk IOPS, sebagian besar komponen sudah dimuat ke dalam RAM, dan disk tidak dimuat. Namun, jika Anda menghemat uang dan menempatkan diri Anda pada disk yang lambat, Anda akan mendapatkan reboot yang lama dan bangun dari mode tidur karena rendahnya kecepatan membaca swap dan file konfigurasi.

Pertimbangkan faktor ini jika sangat penting bagi Anda untuk dengan cepat meningkatkan mesin virtual setelah reboot. Dalam kasus lain, Anda dapat menyimpan.

Disk di dalam basis data

Sangat sering, disk di bawah basis data diambil "untuk pertumbuhan." Ini adalah kesalahan umum untuk sistem cloud. Jika Anda membutuhkan 60 GB, maka ambil sebanyak yang Anda butuhkan dengan margin kecil. Bersyarat 200 GB disk cepat akan menghabiskan dana dan menganggur.

Berbeda dengan server besi, tidak ada masalah memperluas disk secara bertahap sesuai kebutuhan. Hanya saja, jangan lupa untuk menggantung pemantauan dengan pemicu untuk meluap disk agar tidak ketinggalan momen ketika saatnya untuk memperluas ruang. Jika Anda ingin melakukannya dengan sangat indah, Anda dapat mencoba menambah ruang secara otomatis saat ia mengisi API.

Satu-satunya minus dari pendekatan ini adalah bahwa Anda tidak dapat mengurangi ukuran disk, hanya mengubah arah ekspansi. Jika Anda masih perlu menguranginya, maka prosedur ini dilakukan dengan mentransfer data ke volume yang lebih kecil dan menghapus disk lama. Jangan lupa tentang pencadangan dan pengujian menyeluruh pada tahap ini.

Jangan lupa untuk membuang log pada penyimpanan lambat yang terpisah agar tidak membuang ruang berharga pada disk cepat dari database. Mereka cenderung menyerap ruang dengan sangat cepat, terutama dalam kasus MS SQL. Juga sangat diinginkan untuk mengecualikan log dari gambar cadangan reguler.

Jaringan

Kami melakukan hal yang sama dengan Jaringan: kami tidak mengejar angka bulat 1-10-100 megabit, tetapi segera ambil 45 megabit jika Anda memiliki rata-rata beban saluran sekitar 40. Gunakan sumber daya sebanyak yang Anda butuhkan.

Klarifikasi kemungkinan mengontrol parameter ini di pihak Anda. Di tempat kami, klien sendiri tidak dapat mengubahnya, yaitu pay-as-you-go tidak berfungsi, dan mengubah lebar saluran dimungkinkan sebulan sekali. Namun, ada cloud tempat pengaturan ini dikonfigurasi secara real time.

Di cloud berbasis vCloud Director, ada hal hebat tentang NSX Edge - router virtual. Ini gratis dan dapat menggantikan solusi yang lebih mahal yang membutuhkan kapasitas tambahan dan membeli lisensi. Ini memiliki penyeimbang yang dalam situasi sederhana dapat menggantikan solusi seperti Haproxy dan alat virtual Citrix NetScaler. Tidak perlu membeli lisensi untuk produk komersial, dan Anda tidak membayar sumber daya NSX Edge. Secara default.

Jika perlu, NSX Edge dapat diskalakan. Mampu bekerja sebagai VPN dengan tiga jenis:

IPsec VPN tunnel Site-to-Site - untuk mengatur saluran aman antara cloud dan kantor atau cloud lain di mana sumber daya klien berada.
SSL VPN — , Checkpoint Cisco Fortigate.
L2VPN — , IPSEC Site-to-Site, L2.

CPU

Di sini Anda dapat menyimpan beberapa opsi.

Pertama, Anda perlu hati-hati memilih jenis prosesor yang optimal dalam hal frekuensi dan jumlah core. Semuanya akan tergantung pada fitur lisensi perangkat lunak yang berjalan pada mesin ini. Misalnya, server AD atau server terminal nyaman untuk tetap menggunakan hypervisor dengan sejumlah besar core rentang menengah. Pada server dengan perangkat lunak yang dilisensikan oleh jumlah inti, frekuensi inti tunggal sudah menjadi penting. Mesin seperti itu lebih mahal, tetapi lebih menguntungkan dalam hal kinerja per inti.

Sama sekali tidak perlu menggunakan prosesor yang sama pada semua mesin Anda. Selain itu, kombinasi instance dengan frekuensi inti 2,4 GHz dan, misalnya, 3,1 GHz mungkin lebih menarik secara ekonomis.

Arsitektur hibrida juga dapat digunakan. Jika Anda memiliki infrastruktur sendiri dan Anda tidak ingin mentransfer semuanya, maka solusi campuran akan menjadi solusi yang baik, ketika sebagian berputar di kantor dan yang lainnya di cloud. Pada saat yang sama, sumber daya cloud hanya diambil untuk memperlancar beban puncak infrastruktur mereka sendiri.

Harap dicatat: RAM akan mengurangi RAM dan CPU hanya ketika VM dimatikan, jika tidak sistem akan panik. Anda dapat memperluas sumber daya pada mesin yang sedang berjalan jika OS mendukung dan mode penambahan panas diaktifkan.

Cadangkan

Saat menggunakan layanan Cadangan, klien membayar untuk dua hal: untuk jumlah VM dan jumlah data pada ruang disk. Sekali lagi kita mulai dengan analisis.

Pikirkan apakah Anda memerlukan salinan Active Directory setahun yang lalu, atau jika cadangan harian tambahan satu hingga dua minggu sudah cukup. Tentukan berapa lama data yang rusak dapat tidak terdeteksi, dan konfigurasikan penyimpanan cadangan yang sesuai. Mesin yang berfungsi, di mana layanan hanya berputar, sebagai aturan, tidak masuk akal untuk menyimpan lebih dari satu minggu. Dalam kasus database, mungkin perlu untuk memulihkan dari salinan enam bulan yang lalu jika seseorang mengacaukan data, tetapi ini tidak akan segera diketahui.

Poin kedua adalah kecepatan pemulihan. Jika layanan memiliki cadangan, maka Anda dapat membatasi diri hingga salinan lengkap dan inkremental. Dalam hal ini, salinan terakhir dipulihkan, tetapi sebelum itu, semua perubahan dari salinan tambahan harus dipertimbangkan secara bertahap. Ini waktu yang lama. Tetapi dalam kasus node cadangan bekerja, layanan akan terus berfungsi sementara salah satu node dipulihkan.

Jika tidak ada cadangan untuk beberapa alasan, maka Anda harus berpikir tentang menyimpan cadangan penuh saat ini tanpa kenaikan. Makan lebih banyak tempat, tetapi lebih cepat digunakan dan meminimalkan waktu henti. Perbedaan kecepatan bisa satu setengah hingga dua kali.

Jika Anda perlu menyimpan cadangan untuk waktu yang lama, maka Anda harus mempertimbangkan opsi penyimpanan dingin. Ini biasanya perpustakaan tape pemulihan lambat. Opsi ini ideal untuk data yang diarsipkan. Contoh yang baik adalah Gletser Amazon, di mana dimulainya penyebaran dari cadangan lama dimulai tiga hingga lima jam setelah permintaan. Secara kondisional, data Anda perlu ditemukan secara fisik, dihapus dari gudang, dan dihitung. Tetapi biaya per gigabyte penyimpanan menjadi jauh lebih menguntungkan.

Kita dapat menggunakan fasilitas penyimpanan dengan kecepatan " Tunggal ". Ini memiliki biaya penyimpanan kecil dengan diskon progresif: semakin banyak penyimpanan yang Anda simpan, semakin murah gigabyte biaya data.

Ringkasan

Anda dapat menghemat sumber daya di cloud hanya jika Anda menganalisis beban dengan hati-hati dan meminimalkan kapasitas cadangan. Mulailah dengan mengumpulkan statistik berkualitas tinggi dan mulai memotong sumber daya dengan seminimal mungkin.

Jika konsumsi node stabil dan tidak berubah - pergi ke infrastruktur Anda sendiri untuk tugas ini atau pilih tarif tetap.

Jangan lupa tentang kemungkinan skema hybrid. Menggunakan sumber daya cloud untuk memuluskan beban puncak yang tidak beraturan cocok dengan konsep pay-as-you-go.

Apa yang harus disimpan di cloud