Klien Turki kami meminta kami mengonfigurasi cadangan dengan benar untuk pusat data mereka. Kami melakukan proyek serupa di Rusia, namun di sini ceritanya lebih tentang meneliti cara terbaik untuk melakukannya.
Mengingat: ada penyimpanan S3 lokal, ada Veritas NetBackup, yang telah memperoleh fungsionalitas baru yang diperluas untuk memindahkan data ke penyimpanan objek, sekarang dengan dukungan untuk deduplikasi, dan ada masalah dengan ruang kosong di penyimpanan lokal ini.
Tugasnya adalah membuat segalanya agar proses penyimpanan backup menjadi cepat dan murah.
Sebenarnya, sebelum ini, semua yang ada di S3 hanyalah file, dan ini adalah cetakan lengkap dari mesin penting di pusat data. Artinya, ini tidak terlalu dioptimalkan, tetapi semuanya berfungsi pada awalnya. Sekarang saatnya untuk mencari tahu dan melakukannya dengan benar.
Gambar menunjukkan apa yang kami dapatkan:
Seperti yang Anda lihat, pencadangan pertama dilakukan dengan lambat (70 Mb/s), dan pencadangan berikutnya pada sistem yang sama jauh lebih cepat.
Sebenarnya lebih jauh lagi ada sedikit lebih detail mengenai fitur apa saja yang ada.
Log cadangan bagi mereka yang siap membaca setengah halaman dumpPenuh dengan pemindaian ulang
18 Des 2018 12:09:43 PM β Info bpbkar (pid=4452) akselerator mengirim 14883996160 byte dari 14883994624 byte ke server, optimasi 0.0%
18 Des 2018 12:10:07 - Info NBCC (pid=23002) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=Statistik PDDO (stream multi-thread yang digunakan) untuk (NBCC): dipindai: 14570817 KB, CR terkirim: 1760761 KB, CR dikirim melalui FC: 0 KB, dedup: 87.9%, cache dinonaktifkan
Penuh
18 Des 2018 12:13:18 PM β Info bpbkar (pid=2864) akselerator mengirim 181675008 byte dari 14884060160 byte ke server, optimasi 98.8%
18 Des 2018 12:13:40 - Info NBCC (pid=23527) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=Statistik PDDO untuk (NBCC): dipindai: 14569706 KB, CR terkirim: 45145 KB, CR dikirim melalui FC: 0 KB, dedup: 99.7%, cache dinonaktifkan
Tambahan
18 Des 2018 12:15:32 PM β Info bpbkar (pid=792) akselerator mengirim 9970688 byte dari 14726108160 byte ke server, optimasi 99.9%
18 Des 2018 12:15:53 - Info NBCC (pid=23656) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=Statistik PDDO untuk (NBCC): dipindai: 14383788 KB, CR terkirim: 15700 KB, CR dikirim melalui FC: 0 KB, dedup: 99.9%, cache dinonaktifkan
Penuh
18 Des 2018 12:18:02 PM β Info bpbkar (pid=3496) akselerator mengirim 171746816 byte dari 14884093952 byte ke server, optimasi 98.8%
18 Des 2018 12:18:24 - Info NBCC (pid=23878) StorageServer=PureDisk_rhceph_rawd:s3.cloud.ngn.com.tr; Report=Statistik PDDO untuk (NBCC): dipindai: 14569739 KB, CR terkirim: 34120 KB, CR dikirim melalui FC: 0 KB, dedup: 99.8%, cache dinonaktifkan
Apa masalahnya
Pelanggan ingin membuat cadangan sesering mungkin dan menyimpannya semurah mungkin. Yang terbaik adalah menyimpannya dengan harga murah di penyimpanan objek seperti S3, karena ini adalah yang termurah dengan biaya layanan per Megabyte sehingga Anda dapat mengembalikan cadangan dalam waktu yang wajar. Ketika cadangannya banyak, itu menjadi tidak terlalu murah, karena sebagian besar penyimpanan ditempati oleh salinan data yang sama. Dalam kasus HaaS rekan Turki, penyimpanan dapat dipadatkan sekitar 80-90%. Jelas bahwa ini berkaitan dengan spesifiknya, tetapi saya pasti akan mengandalkan setidaknya 50% kakek.
Untuk mengatasi masalah tersebut, vendor utama telah lama membuat gateway ke Amazon S3. Semua metode mereka kompatibel dengan S3 lokal selama mendukung Amazon API. Di pusat data Turki, cadangan dibuat ke S3 kami, serta di βKompresorβ T-III di Rusia, karena skema kerja ini telah bekerja dengan baik untuk kami.
Dan S3 kami sepenuhnya kompatibel dengan metode pencadangan Amazon S3. Artinya, semua alat pencadangan yang mendukung metode ini memungkinkan Anda menyalin semuanya ke penyimpanan tersebut βdi luar kotakβ.
Veritas NetBackup menambahkan fitur CloudCatalyst:
Artinya, antara mesin yang perlu dicadangkan dan gateway, terdapat server Linux perantara yang dilalui lalu lintas cadangan dari agen SRK dan dihapus duplikatnya dengan cepat sebelum mentransfernya ke S3. Jika sebelumnya ada 30 cadangan 20 GB dengan kompresi, sekarang (karena kesamaan mesin) volumenya menjadi 90% lebih kecil. Mesin deduplikasi digunakan sama seperti saat menyimpan pada disk biasa menggunakan Netbackup.
Inilah yang terjadi sebelum server perantara:
Kami menguji dan sampai pada kesimpulan bahwa ketika diterapkan di pusat data kami, hal ini menghemat ruang penyimpanan S3 bagi kami dan pelanggan. Sebagai pemilik pusat data komersial, tentu saja, kami mengenakan biaya sesuai dengan volume yang ditempati, namun tetap sangat menguntungkan bagi kami juga - karena kami mulai menghasilkan uang di tempat yang lebih terukur dalam perangkat lunak, dan bukan dari menyewa perangkat keras. Nah, ini adalah pengurangan biaya internal.
Log228 Pekerjaan (0 Antrian 0 Aktif 0 Menunggu Coba Lagi 0 Ditangguhkan 0 Tidak Selesai 228 Selesai β 13 dipilih)
(Filter Diterapkan [13])
Id Pekerjaan Jenis Status Status Detail Status Kebijakan Pekerjaan Jadwal Pekerjaan Klien Media Server Waktu Mulai Waktu Berakhir Waktu Akhir Unit Penyimpanan Percobaan Pengoperasian Kilobyte File Nama Jalur % Selesai (Perkiraan) Pekerjaan PID Pemilik Salin ID Pekerjaan Induk KB/Dtk Aktif Mulai Aktif Sesi Profil Robot Vault Berlalu Media ID untuk Mengeluarkan Pergerakan Data Tipe Off-Host Tingkat Deduplikasi Prioritas Master Instans Optimasi Akselerator Transportasi atau Host Berbagi Basis Data
β 1358 Snapshot Selesai 0 VMware β NGNCloudADC NBCC 18 Des 2018 12:16:19 PM 00:02:18 18 Des 2018 12:18:37 PM STU_DP_S3_****backup 1 100% root 1358 18 Des 2018 12 :16:27 PM 00:02:10 Disk Pemulihan Instan Standar WIN-*********** 0
1360 Pencadangan Selesai 0 VMware Penuh NGNCloudADC NBCC 18 Des 2018 12:16:48 00:01:39 18 Des 2018 12:18:27 STU_DP_S3_****cadangan 1 14,535,248 149654 100% 23858 root 1358 335,098 .18 2018 Desember , 12 16:48:00 01:39:0 Disk Pemulihan Instan Standar WIN-*********** 99.8 99% XNUMX%
1352 Snapshot Selesai 0 VMware - NGNCloudADC NBCC 18 Des 2018 12:14:04 PM 00:02:01 18 Des 2018 12:16:05 PM STU_DP_S3_****backup 1 100% root 1352 18 Des 2018 12: 14:14 00:01:51 Disk Pemulihan Instan Standar WIN-*********** 0
1354 Pencadangan Selesai 0 VMware Inkremental NGNCloudADC NBCC 18 Des 2018 12:14:34 00:01:21 18 Des 2018 12:15:55 STU_DP_S3_****cadangan 1 14,380,965 147 100% 23617 root 1352 500,817, 18 2018 Desember , 12 14:34:00 PM 01:21:0 Disk Pemulihan Instan Standar WIN-*********** 99.9 100% XNUMX%
1347 Snapshot Selesai 0 VMware - NGNCloudADC NBCC 18 Des 2018 12:11:45 PM 00:02:08 18 Des 2018 12:13:53 PM STU_DP_S3_****backup 1 100% root 1347 18 Des 2018 12: 11:45 00:02:08 Disk Pemulihan Instan Standar WIN-*********** 0
1349 Pencadangan Selesai 0 VMware Penuh NGNCloudADC NBCC 18 Des 2018 12:12:02 00:01:41 18 Des 2018 12:13:43 STU_DP_S3_****cadangan 1 14,535,215 149653 100% 23508 root 1347 316,319 .18 2018 Desember , 12 12:02:00 01:41:0 Disk Pemulihan Instan Standar WIN-*********** 99.7 99% XNUMX%
1341 Snapshot Selesai 0 VMware - NGNCloudADC NBCC 18 Des 2018 12:05:28 PM 00:04:53 18 Des 2018 12:10:21 PM STU_DP_S3_****backup 1 100% root 1341 18 Des 2018 12: 05:28 00:04:53 Disk Pemulihan Instan Standar WIN-*********** 0
1342 Pencadangan Selesai 0 VMware Full_Rescan NGNCloudADC NBCC 18 Des 2018 12:05:47 PM 00:04:24 18 Des 2018 12:10:11 PM STU_DP_S3_****backup 1 14,535,151 149653 100% 22999 root 1341 70,380 18 2018 Desember 12 05 47:00:04 24:0:87.9 Disk Pemulihan Instan Standar WIN-*********** 0 XNUMX% XNUMX%
1339 Snapshot Selesai 150 VMware - NGNCloudADC NBCC 18 Des 2018 11:05:46 00:00:53 18 Des 2018 11:06:39 STU_DP_S3_****backup 1 100% root 1339 18 Des 2018 11: 05:46 00:00:53 Disk Pemulihan Instan Standar WIN-*********** 0
1327 Snapshot Selesai 0 VMware - *******.********.cloud NBCC 17 Des 2018 12:54:42 05:51:38 17 Des 2018 6:46:20 STU_DP_S3_****backup 1 100% root 1327 17 Des 2018 12:54:42 PM 05:51:38 Disk Pemulihan Instan Standar WIN-*********** 0
1328 Pencadangan Selesai 0 VMware Penuh *******.********.cloud NBCC 17 Des 2018 12:55:10 05:29:21 17 Des 2018 6:24:31 STU_DP_S3_****backup 1 222,602,719 258932 100% 12856 root 1327 11,326 17 Des 2018 12:55:10 05:29:21 Disk Pemulihan Instan Standar WIN-************ 0 87.9% 0%
1136 Snapshot Selesai 0 VMware - *******.********.cloud NBCC 14 Des 2018 4:48:22 04:05:16 14 Des 2018 8:53:38 STU_DP_S3_****backup 1 100% root 1136 14 Des 2018 4:48:22 PM 04:05:16 Disk Pemulihan Instan Standar WIN-*********** 0
1140 Pencadangan Selesai 0 VMware Full_Scan *******.********.cloud NBCC 14 Des 2018 4:49:14 03:49:58 14 Des 2018 8:39:12 STU_DP_S3_****backup 1 217,631,332 255465 100% 26438 root 1136 15,963 14 Des 2018 4:49:14 03:49:58 Disk Pemulihan Instan Standar WIN-********** 0 45.2% 0%
Akselerator memungkinkan Anda mengurangi lalu lintas dari agen, karena Hanya perubahan data yang dikirimkan, yaitu bahkan pencadangan penuh tidak diunggah seluruhnya, karena server media mengumpulkan pencadangan penuh berikutnya dari pencadangan tambahan.
Server perantara memiliki penyimpanannya sendiri, di mana ia menulis βcacheβ data dan memelihara database untuk deduplikasi.
Arsitektur lengkapnya terlihat seperti ini:
- Server master mengelola konfigurasi, pembaruan, dll. dan terletak di cloud.
- Server media (mesin *nix perantara) harus ditempatkan paling dekat dengan sistem redundan dalam hal aksesibilitas jaringan. Di sini, deduplikasi cadangan dari semua mesin yang dicadangkan dilakukan.
- Pada mesin yang dicadangkan terdapat agen yang umumnya hanya mengirim ke server media apa yang tidak ada dalam penyimpanannya.
Semuanya dimulai dengan pemindaian penuh - ini adalah cadangan penuh yang lengkap. Pada titik ini, server media mengambil semuanya, menghapus duplikatnya dan mentransfernya ke S3. Kecepatan ke server media rendah, tetapi kecepatannya lebih tinggi. Batasan utamanya adalah kekuatan komputasi server.
Pencadangan berikut ini dibuat lengkap dari sudut pandang semua sistem, namun kenyataannya pencadangan tersebut seperti pencadangan penuh sintetis. Artinya, transfer dan perekaman sebenarnya ke server media hanya terjadi pada blok data yang belum pernah ditemukan dalam pencadangan VM sebelumnya. Dan hanya blok data yang hashnya tidak ada dalam database deduplikasi server media yang ditransfer dan dicatat di S3. Dengan kata sederhana, ini adalah sesuatu yang belum pernah terlihat pada cadangan satu VM sebelumnya.
Selama pemulihan, server media meminta objek deduplikasi yang diperlukan dari S3, merehidrasinya dan mentransfernya ke agen IRB, mis. perlu memperhitungkan volume lalu lintas selama pemulihan, yang akan sama dengan volume sebenarnya data yang dipulihkan.
Begini tampilannya:
Dan ini potongan log lainnya169 Pekerjaan (0 Antrian 0 Aktif 0 Menunggu Coba Lagi 0 Ditangguhkan 0 Tidak Selesai 169 Selesai β 1 dipilih)
Id Pekerjaan Jenis Status Status Detail Status Kebijakan Pekerjaan Jadwal Pekerjaan Klien Media Server Waktu Mulai Waktu Berakhir Waktu Akhir Unit Penyimpanan Percobaan Pengoperasian Kilobyte File Nama Jalur % Selesai (Perkiraan) Pekerjaan PID Pemilik Salin ID Pekerjaan Induk KB/Dtk Aktif Mulai Aktif Sesi Profil Robot Vault Berlalu Media ID untuk Mengeluarkan Pergerakan Data Tipe Off-Host Tingkat Deduplikasi Prioritas Master Instans Optimasi Akselerator Transportasi atau Host Berbagi Basis Data
- 1372 Pemulihan Selesai 0 NBPR01 NBCC 19 Des 2018 1:05:58 00:04:32 19 Des 2018 1:10:30 1 14,380,577 1 100% 8548 ROOT 1372 70,567 19 Des 2018 1:06 :00 PM 00:04:30 MENANG-*********** 90000
Integritas data dijamin oleh perlindungan S3 itu sendiri - terdapat redundansi yang baik di sana untuk melindungi dari kegagalan perangkat keras seperti spindel hard drive yang mati.
Server media memerlukan cache sebesar 4 TB - ini adalah rekomendasi ukuran minimum Veritas. Lebih banyak lebih baik, tapi itulah yang kami lakukan.
Total
Saat mitra memberikan 3 GB ke S20 kami, kami menyimpan 60 GB, karena kami menyediakan tiga kali reservasi geografis data. Sekarang lalu lintasnya jauh lebih sedikit, yang baik untuk saluran dan tarif penyimpanan.
Dalam hal ini, rute ditutup melewati βInternet besarβ, tetapi Anda dapat mengarahkan lalu lintas melalui VPN L2 melalui Internet, tetapi lebih baik menginstal server media sebelum masuknya penyedia.
Jika Anda tertarik untuk mempelajari fitur-fitur ini di pusat data Rusia kami atau memiliki pertanyaan tentang penerapan di rumah, tanyakan di komentar atau melalui email [email dilindungi].
Sumber: www.habr.com