Saya harus segera memperingatkan Anda: ini bukan cerita di
mana tikus itu disobek ke tempat sampah . Hanya sedikit kisah kecil "bagaimana orang melakukannya" yang mungkin berguna bagi administrator. Dan mungkin tidak. Kami memiliki banyak pelanggan yang agak besar, dan mereka, karenanya, memiliki admin yang kompeten. Dari pengalaman, saya akan mengatakan: sering kali lebih berpengalaman di mana ada batasan anggaran yang ketat.
Kami memiliki pelanggan yang menjual kembali cloud kami (ternyata), ada kontrol atas memanggang roti dari cloud, bahkan ada CTF yang dikerahkan untuk melatih para peretas. Tapi mari kita mulai dengan penyeberangan, termasuk yang muncul karena jalanan Moskow yang digali digali oleh excavator.
Kecepatan data tertinggi
Pindah dari pusat data di wilayah ke
cloud kami . Karena ada banyak data, pelanggan memutuskan untuk hanya memuat disk ke truk biasa. Karena tidak semuanya berjalan baik dengan truk, ia mengemudi sebagai akibatnya di kompartemen di kereta. Saya langsung membayangkan: Saya membeli semua yang ada di kompartemen, memaksanya masuk ke dalam kotak dengan besi, mengunci diri dan paranoid. Sebagai hasilnya, saya menetapkan rekor kami untuk kecepatan transfer data, seperti dalam lelucon lama tentang sebuah truk dengan cakram.
Bergerak massal
Ketika Moskow mulai digali, seluruh gelombang permintaan untuk pindah pergi ke kami. Seseorang memotong kabel listrik, dan sementara itu diperbaiki, orang-orang melaju ke awan (karena kami bermigrasi dengan cepat di bawah garansi kontrak). Terlihat lebih dekat, tetap, perlahan-lahan mentransfer aplikasi dari server mereka kepada kami saat perangkat keras dihapus dari jaminan.
Kisah yang paling menarik adalah dengan satu ruang server kecil di Khimki. Di sana, direktur keuangan tidak memberikan uang untuk modernisasi pada prinsipnya, mereka mengeksploitasi besi dalam siklus 5-6 tahun.
Konsekuensi logis dari pendekatan ini adalah bahwa pada akhir siklus semuanya bernafas di udara dan ada masalah bahkan dengan disk untuk database pertempuran. Setiap minggu, sesuatu keluar dari mereka, mereka memeriksa aplikasi yang paling tidak kritis dan memotongnya. Akibatnya, penggalian oleh penggali Khimki memberi administrator kesempatan langka untuk tetap setuju untuk pindah ke awan.
Kisah serupa terjadi pada rekonstruksi jalan raya Kaluga, tetapi di sana perusahaan segera memindahkan kantor di bawah bisnis ini dan memutuskan untuk tidak membuat simpul server di tempat baru, tetapi untuk langsung menuju pusat data kami.
Langkah mendesak
Jika Anda perlu bergerak sangat mendesak, Anda bisa membawa penyimpanan fisik. Ada cerita seperti itu, dan bukan tanpa keingintahuan. Admin pelanggan memberi kami besi, mengatakan: "Kelebihan muatan." "Apa itu?" - kami bertanya. "Segala macam dokumen penting," jawabnya. File mulai diseret - administrator hanya membaca nama mereka dan merangkak di sepanjang dinding dengan tawa. Di fileshare dengan dokumen-dokumen penting, yang, pada kenyataannya, hampir 9 TB dikumpulkan, terletak seri “House MD”. Tentu, kemudian mereka membersihkan bahwa pelanggan tidak terburu-buru dihapus.
Flash drive yang terlupakan
Kami mengerahkan lingkungan baru setelah bergerak sesuai rencana. Kami mengambil aplikasi dengan admin pelanggan, dan kemudian satu membanting dirinya sendiri di dahi. Dia berkata: "Mereka lupa flash drive." Nah, lupa dan lupa, lalu bawa. Sesuatu bisnis. Ternyata ini bukan hanya flash drive, tetapi kunci otorisasi untuk aplikasi bisnis-kritis. Saya harus bergegas ke pusat data lama di malam hari, menemukan flash drive di salah satu server, merobeknya dan datang kepada kami. Kami memasukkannya ke hub USB standar untuk cloud, mempresentasikannya ke mesin virtual seolah-olah terjebak dalam port fisik, semuanya naik.
Monitor di cloud
Panggil: "Apakah Anda memiliki monitor di cloud?" Kami: "APA?" Pelanggan: “Yah, saya membawa server ke sini, akses jarak jauh tidak dikonfigurasi di sana. Butuh monitor di cloud. " Ternyata kemudian, mereka membeli komputer desktop baru (tentang level game) dan menyebarkan layanan di atasnya. Konfigurasi hampir seperti server, mereka mengisinya dengan memori hampir hingga batasnya. Jadi dia dibawa ke awan, terjebak dalam vilan dengan mesin virtualnya dan pergi. Ketika crash, mereka akan menyingkirkannya, tetapi untuk saat ini canggung di rak dan bersaing dengan server dalam kecepatan. Kami punya monitor, jadi kami baru mengaturnya.
Autoscaling
Salah satu pelanggan ritel besar melakukan penskalaan, yaitu, konsumsi sumber daya sesuai kebutuhan. Mereka memiliki sistem pemantauan Zabbix, pemicu untuk memuat setiap layanan dikonfigurasi di dalamnya. Katakanlah node web. Ketika rata-rata muat mencapai 0,8, Zabbix menarik skrip Terraform eksternal dan menciptakan mesin virtual baru melalui API. Itu akan merayap dalam menggunakan Ansible, paket ditarik bersama, rilis sedang dilakukan. Penyeimbang menerimanya dan memperbarui konfigurasi. Penempatan membutuhkan waktu 5-10 menit. Ketika beban total turun ke tingkat tertentu, simpul inilah yang dihapus.
Database mereka dikonfigurasikan sebagai master-master, oleh karena itu ia juga mudah diskalakan. Omong-omong, kinerja disk bersama kami umumnya diskalakan dengan benar oleh satu permintaan ke API, mereka dan sejumlah klien lain secara aktif menggunakannya.
Pada akhirnya, seperti tongkat penyangga, tapi indah. Penghematan sekitar 25–30% bila sepenuhnya disiapkan untuk puncak.
Autoscaling for Legacy
Perusahaan negara melakukan penskalaan lain. Mereka memiliki arsitektur lama (baca: sesuatu berfungsi pada Fortran, sesuatu pada setengah sumbu, di beberapa tempat Anda perlu menjalankan hypervisor lama di hypervisor baru untuk kompatibilitas). Mereka tidak dapat menempel bersama di mobil secara horizontal. Tetapi mereka mematikan VM mereka di malam hari dan memulai kembali dengan jenis sumber daya yang mudah. Di sore hari - mesin cloud paling kuat, pada 12 malam mereka sebagian berhenti dan bukannya memulai yang sama, tetapi jauh lebih murah, dengan akses lebih lambat ke disk dan dengan kuota berbeda untuk core. Ini menumpahkan kepalanya di Exapark - sistem kami yang menggantung dari luar. Pada 6-7 pagi semuanya mengulangi dalam urutan terbalik. Fungsionalitas ini tersedia untuk semua pelanggan cloud, tetapi di sinilah admin langsung tahu persis apa yang mereka inginkan dan bagaimana. Hasilnya adalah penghematan yang baik, karena pembayaran untuk sumber daya cloud adalah setiap jam.
Jenis akses yang tidak biasa
Kami memiliki penyimpanan objek yang kompatibel dengan AWS. Sebagai aturan, biasanya digunakan sebagai S3. Tetapi salah satu pelanggan berlaku langsung melalui aplikasi seluler tanpa penempatan ulang menengah. Aplikasi untuk aplikasi iOS dan Android, ribuan merchandis mengerjakannya. Mereka mengunggah semua foto dan laporan di sana. Langsung dari ponsel ke penyimpanan objek. Aplikasi, omong-omong, ditulis menggunakan AWS SDK, hanya titik akhir lainnya.
Kami menarik saklar dalam sebulan
Ada perusahaan yang membeli bisnis yang siap mati dan memperpanjang hidup mereka. Ada satu perusahaan Prancis yang, karena sanksi, akan meninggalkan Rusia. Pelanggan kami mengalahkan bisnis ini. Seluruh infrastruktur Perancis berada di Moskow di kantor biasa, rak server yang padat. Selama satu bulan itu perlu untuk mentransfer semuanya ke cloud sekaligus. Jika Anda tidak punya waktu - cukup potong lampu dan hanya itu. Dan ada pengiriman dari gudang, mobil sedang menunggu. Dan masih ada beberapa hal yang tidak dapat diverifikasi sampai infrastruktur lama dimatikan sepenuhnya. Secara alami, kami tidak ingin tetap tanpa pengiriman pada hari pertama, jadi kami setuju dengan admin bahwa pada hari Minggu sebelum akhir bulan mereka memadamkan node server kantor, kami menyaksikan bagaimana semuanya baru terungkap. Telah bangkit. Kesulitan lain adalah bahwa perusahaan induk tidak memberikan akses ke sarana asli untuk mentransfer database, mereka juga menderita.
Saat pergi, padamkan VM
Salah satu pelanggan kami - agregator - hampir seluruhnya terdiri dari pengembang. Mereka sangat cepat dan dibuat dengan sangat baik. Kami sebagian besar melaju ke awan untuk lingkungan pengujian. Sebelumnya, mereka memiliki masalah dengan fakta bahwa banyak tim pengembangan berbeda mendatangi administrator dan menarik: "Berikan sumber daya." Tidak jelas berapa nilainya: tidak ada pembagian anggaran, itu dianggap secara manual. Mereka pindah ke cloud kami, menutupi semuanya dengan skrip otomatisasi dan berjalan berkeliling. Setelah hari pertama, mereka tidak memiliki satu entri pun ke GUI dan hanya beberapa entri ke konsol - mereka melakukan segalanya dalam infrastruktur yang sangat otomatis. Alat otomasi mereka dapat menyebarkan apa pun yang mereka inginkan kapan saja. Sekarang pukulan pemodal - mereka bertanya, "pergi, untuk mematikan mobil." Sehingga setelah tes semua orang membersihkan setelah dirinya sendiri. Mengingat bahwa mereka menulis infrastruktur mereka sepenuhnya sebagai kode (IaaC), saya pikir mereka juga mengotomatisasi ini. Jika belum selesai.
Pengembang lain memiliki gambaran serupa - mereka menggunakan fungsionalitas standar kami untuk akuntansi proyek. Ini adalah peran yang terpisah untuk setiap kelompok admin: jelas berapa banyak uang yang dihabiskan untuk jenis kegiatan apa. Akuntansi proyek adalah peran yang melaluinya Anda dapat menciptakan cloud pribadi pada intinya, dan menggunakan sumber daya di dalamnya. Hak dan akses terpotong sesuka Anda, ada batas atas, ada tagihan terpisah.
Penggunaan yang menyenangkan
Kami biasanya tidak tahu bagaimana pelanggan menggunakan cloud kami. Tetapi kadang-kadang administrator sendiri memberi tahu dan menunjukkan. Jadi, simpul blockchain kami digergaji, ada CTF dari satu perusahaan keamanan - itu adalah simulator langsung dari jaringan perusahaan perusahaan, Anda harus terhubung di sana dan menghancurkan semuanya. Digunakan untuk melatih karyawan dan konsumen akhir. Pelanggan lain mengoordinasikan pembersihan melalui cloud, ada manajemen pemanggangan roti (ACS TP), ada layanan medis dengan konsultasi video dengan pasien (mereka memiliki sejarah yang sangat rumit dengan data pribadi, ada segmen berdedikasi, khusus dilindungi). Masih ada beberapa pelanggan - beberapa menjual layanan, dan yang kedua menulis perangkat lunak terlebih dahulu. Dari berbagai negara. Dan keduanya berdiri berdampingan di awan. Perusahaan ritel lain hanya berdiri bersama kami untuk menangani perampok - mereka terputus sebulan sekali pada node server. Ada permintaan seperti layanan untuk spammer: “Kami ingin berlokasi di Rusia. Untuk mengirim beberapa juta surat per jam. Itu perlu di Federasi Rusia. Dan perangkat lunaknya adalah bahasa Rusia. " Terakhir ditolak. Pengontrol cahaya dari salah satu kantor (pencahayaan dinamis dari cuaca dan kehadiran orang-orang di kantor) diteruskan langsung ke cloud sehingga kontraktor layanan dapat pergi ke sana. Ini adalah IoT pertama kami di cloud.