Setiap pengembang menginginkan stand dev mereka sendiri. Setiap tester menginginkan bangku tes mereka sendiri. Dan setiap spesialis pra-produksi menginginkan stand sendiri - untuk akhirnya memeriksa semuanya dan berlatih peluncuran di prod. Ketika semua Daftar Keinginan ini bertemu dalam pemrosesan - salah satu sistem bank terbesar dan paling aktif - biaya infrastruktur membuat Anda menggaruk kepala dan mencari "opsi". Kami akan memberi tahu tentang apa yang kami temukan di pos ini.
Volume pemrosesan basis data di perusahaan kami adalah sekitar 6 TB. Pada satu salinan basis data, pengembang saling mengganggu, sehingga jumlah aktual ruang yang digunakan oleh pangkalan tumbuh dengan cepat dan proporsional. Meskipun seberapa cepat ... terlalu cepat untuk layanan pengawalan dan tidak cukup cepat bagi mereka yang membutuhkan salinan database. Dan inilah alasannya.
Untuk pengujian, perlu bahwa dudukan pengujian sepenuhnya konsisten dengan versi produksi saat ini (hal yang sama berlaku untuk dudukan pra-produksi). Cadangan utama sistem disalin sepanjang hari, kemudian digunakan untuk stand. Selama operasi yang panjang ini, stan tidak tersedia, jadi penyalinan akan dibawa ke akhir pekan dan hari libur ketika tidak ada yang bekerja dengan stan. Kami mendapat keterlambatan 1 hingga 5 hari. Untuk menyetujui terlebih dahulu proses penyalinan itu sendiri, juga membutuhkan waktu - kami memiliki beberapa bangku tes, biasanya dari tiga hingga enam. Kami menambahkan 2-3 hari untuk mengoordinasikan waktu siaga siaga. Sebelum sampai ke administrator untuk persetujuan, aplikasi masih dalam antrian. Secara total, kami mendapat penundaan yang sangat besar.
Apa yang membantu Delphix
Apa yang bisa mempercepat proses dan menghemat ruang? Virtualisasi basis data. Kami mempertimbangkan berbagai opsi: Oracle SnapClone, NetApp + Oracle Cloud, hanya snapshots pada array. Semuanya membutuhkan pengaturan yang rumit. Solusi Oracle, apalagi, hanya bekerja dengan database Oracle.
Kemudian saya melihat Delphix. Mudah diimplementasikan, mendukung database yang berbeda - Oracle, SQL Server, DB2, Sybase ASE. Antarmuka disediakan untuk semua operasi. Melalui itu, pengembang dan penguji dapat secara mandiri mengelola salinan mereka - memperbarui, menyimpan / mengembalikan keadaan, menghentikan / memulai, dll. Ada juga API dan CLI untuk integrasi dengan sistem CI / CD atau prosesnya.
Penyebaran Delphix sendiri tidak memakan waktu lama - beberapa jam. Sumber dapat dihubungkan lebih lama, di sini waktu sebanding dengan ukuran. Dalam kasus kami, sumbernya adalah salinan penjualan dari database, dan koneksinya memakan waktu hampir sehari. Mempersiapkan sumber dan server untuk klon basis data tidak memerlukan tenaga khusus. Di server target, Anda perlu menginstal ORACLE_HOME yang sesuai, dan juga membuat pengguna khusus untuk terhubung. Untuk salinan uji virtual, kami menggunakan server yang sama yang sebelumnya memiliki salinan fisik.
Delphix memungkinkan Anda membuat tribun uji hampir secara real time, tanpa koordinasi apa pun, karena tribun sepenuhnya terisolasi satu sama lain. Beberapa waktu dihabiskan hanya untuk memperbarui basis data ke kondisi saat ini - dari 20 menit hingga beberapa jam, tidak ada pertanyaan tentang hari apa pun.
Kami mencoba melakukan pengujian stres dalam kondisi sedekat mungkin dengan produk. Jika dorongan pada disk fisik - maka beban juga berdiri. Dalam hal ini, tombol Delphix V2P membantu, yang memungkinkan Anda untuk membuat database "jujur" dari yang virtual.
Adapun menghemat ruang disk, pembacaan dasbor Delphix kami, tentu saja, menipu - pengurangan volume 73 kali lipat terlalu luar biasa. Dalam pemrosesan kami, salinan penjualan dengan snapshot harian dan log transaksi yang diarsipkan selama 2 minggu (200 GB per hari) menempati ruang disk sebesar 4,5 TB. 1,5 TB lainnya - sembilan klon ukuran dari 50 hingga 500 GB, masing-masing juga menyimpan riwayat snapshot harian. Secara total, 6 TB diperoleh.
Kami menambahkan 15% ruang kosong (900 GB) sehingga Delphix dapat bekerja secara normal. Dengan demikian, hanya menghabiskan sekitar 7 TB, kita bisa mendapatkan salinan tes dengan data yang relevan pada titik waktu selama dua minggu terakhir.
Sebelumnya, untuk menyimpan sembilan salinan fisik dari basis data dalam 6 TB, kami membutuhkan 54 TB (atau ~ 20 TB dengan memperhitungkan kompresi dengan 2-3 kali penyimpanan). Dan, tidak seperti sistem baru, di sini pengembang tidak dapat mengelola salinan ini dan mengembalikan status sebelumnya - ketika data dihancurkan, itu hanya mungkin untuk memuat ulang dari salinan penjualan.
Delphix juga memungkinkan Anda untuk dengan cepat membuat cabang berbeda dari wadah yang sama untuk proyek yang berbeda - dan semua ini dalam waktu minimal. Pengembang tidak takut merusak data, mereka dapat memutar kembali dan mengembalikan keadaan sebelumnya. Ini memberikan peningkatan kinerja.
Tapi ada nuansa ...
Tayangan dari Delphix sebagian besar positif, meskipun tidak semuanya sempurna. Masalah terbesar adalah menggunakan disk. Setiap blok data disimpan hanya sekali untuk semua salinan virtual, dan sampai semua salinan virtual berhenti menggunakan blok, itu tidak dapat dihapus. Masalah organisasi dapat muncul di sini - tidak semua pengguna siap untuk mendukung siklus hidup singkat stan mereka. Jika bangku tes hidup dengan salinan lama, saya akan menjualnya. Kami memecahkan masalah ini secara luas, dengan memperluas disk, yang dapat dilakukan tanpa mengganggu layanan. Kami memastikan bahwa 15% ruang kosong selalu disimpan. Jika lebih kecil, sistem hanya akan berhenti melakukan operasi apa pun dengan salinan virtual. Meskipun pangkalan itu sendiri akan tetap tersedia.
Untuk sistem dengan disk I / O intensif, bandwidth jaringan cenderung menjadi faktor pembatas. Bergantung pada profil pemuatan khusus, sistem mungkin mulai bekerja lebih baik dengan virtualisasi. Tergantung pada bebannya, rata-rata latensi pembacaan berurutan file db adalah 5-10 ms, yang cukup baik bahkan untuk sistem industri.
Drive "klasik" Delphix terhubung dengan cara apa pun yang mendukung ESX, dan vendor memiliki daftar rekomendasi tentang cara melakukan ini dengan kinerja maksimum. Kami menggunakan SAN. Sistem itu sendiri menyajikan disk di mana file database virtual berada, hanya melalui protokol NFS. Untuk alasan ini, Anda harus berhati-hati tentang bandwidth saluran dan kemacetannya. Dalam kasus kami, masuk akal untuk menempatkan hanya file data untuk Delphix pada array disk sehingga tidak ada aktivitas di bank yang mempengaruhi kecepatan I / O untuk database virtual.
Sekarang kami sedang mengerjakan Delphix 5.1.9, tetapi lihatlah versi 5.2 - di dalamnya antarmuka pengguna telah meninggalkan flash dan, menurut vendor, telah menjadi jauh lebih nyaman. Delphix mengesankan rekan-rekan kami, dan setelah diproses, kami mempertimbangkan untuk mentransfer profil, CRM, dan perbankan internet ke sistem pengembang ini.