BBWC: secara teori ide yang bagus tetapi apakah ada yang pernah menyimpan data Anda?


26

Saya akrab dengan apa yang ingin dilakukan BBWC (cache tulis yang didukung baterai) - dan sebelumnya menggunakannya di server saya bahkan dengan UPS yang baik. Ada beberapa kegagalan yang tidak bisa dilindungi. Saya ingin tahu apakah itu benar-benar menawarkan manfaat nyata dalam praktik.

(NB Saya secara khusus mencari tanggapan dari orang-orang yang memiliki BBWC dan mengalami crash / kegagalan dan apakah BBWC membantu pemulihan atau tidak)

Memperbarui

Setelah umpan balik di sini, saya semakin ragu apakah BBWC menambah nilai.

Untuk memiliki kepercayaan tentang integritas data, sistem file HARUS tahu kapan data telah berkomitmen untuk penyimpanan non-volatil (belum tentu disk - titik saya akan kembali ke). Perlu dicatat bahwa banyak disk berbohong tentang kapan data telah dikomit ke disk ( http://brad.livejournal.com/2116715.html ). Meskipun tampaknya masuk akal untuk berasumsi bahwa menonaktifkan cache di-disk mungkin membuat disk lebih jujur, masih belum ada jaminan bahwa ini adalah masalahnya.

Karena buffer besar biasanya dalam BBWC, penghalang dapat secara signifikan membutuhkan lebih banyak data untuk dikomit ke disk sehingga menyebabkan keterlambatan penulisan: saran umum adalah untuk menonaktifkan penghalang saat menggunakan cache tulis kembali yang tidak mudah menguap (dan untuk menonaktifkan on- caching disk). Namun ini tampaknya akan merusak integritas operasi penulisan - hanya karena lebih banyak data disimpan di penyimpanan non-volatil tidak berarti bahwa itu akan lebih konsisten. Memang, bisa dibilang tanpa demarkasi antara transaksi logis tampaknya ada lebih sedikit kesempatan untuk memastikan konsistensi daripada sebaliknya.

Jika BBWC mengakui hambatan pada saat data memasuki penyimpanan non-volatil (daripada berkomitmen untuk disk) maka akan tampak memenuhi persyaratan integritas data tanpa penalti kinerja - menyiratkan bahwa hambatan masih harus diaktifkan. Namun karena perangkat ini umumnya menunjukkan perilaku yang konsisten dengan membilas data ke perangkat fisik (secara signifikan lebih lambat dengan penghalang) dan saran luas untuk menonaktifkan penghalang, oleh karena itu mereka tidak dapat berperilaku dengan cara ini. KENAPA TIDAK?

Jika I / O dalam OS dimodelkan sebagai serangkaian aliran maka ada beberapa ruang untuk meminimalkan efek pemblokiran penghalang tulis ketika cache tulis dikelola oleh OS - karena pada level ini hanya transaksi logis (aliran tunggal) ) perlu dilakukan. Di sisi lain, BBWC yang tidak tahu bit data mana yang membentuk transaksi harus mengkomit seluruh cache ke disk. Apakah kernel / sistem file benar-benar menerapkan ini dalam praktiknya akan membutuhkan lebih banyak usaha daripada yang ingin saya investasikan saat ini.

Kombinasi disk yang memberi tahu banyak hal tentang apa yang telah dilakukan dan kehilangan daya secara tiba-tiba tidak diragukan lagi mengarah pada korupsi - dan dengan sistem file Jurnal atau log terstruktur yang tidak melakukan fsck penuh setelah pemadaman, kecil kemungkinan korupsi akan terdeteksi apalagi upaya dilakukan untuk memperbaikinya.

Dalam hal mode kegagalan, dalam pengalaman saya pemadaman listrik yang paling tiba-tiba terjadi karena kehilangan daya listrik (mudah dikurangi dengan UPS dan shutdown yang dikelola). Orang-orang menarik kabel yang salah dari rak menyiratkan hygene pusat data yang buruk (pelabelan dan manajemen kabel). Ada beberapa jenis peristiwa kehilangan daya tiba-tiba yang tidak dicegah oleh UPS - kegagalan pada PSU atau VRM, BBWC dengan hambatan akan memberikan integritas data jika terjadi kegagalan di sini, namun seberapa umum kejadian seperti itu? Sangat jarang dinilai dari kurangnya tanggapan di sini.

Tentu saja memindahkan toleransi kesalahan yang lebih tinggi di stack secara signifikan lebih mahal BBWC - namun menerapkan server sebagai cluster memiliki banyak manfaat lain untuk kinerja dan ketersediaan.

Cara alternatif untuk mengurangi dampak kehilangan daya secara tiba-tiba adalah dengan menerapkan SAN - AoE menjadikan ini proposisi praktis (saya tidak benar-benar melihat maksudnya di iSCSI) tetapi sekali lagi ada biaya yang lebih tinggi.


3
Server-server file NetApp telah bertahun-tahun memiliki cache-cache NVRAM, dan saya punya banyak yang kehilangan daya dan tidak membuang sistem file mereka. Sulit untuk membuktikan bahwa sesuatu menyelamatkan seseorang, karena sejak seseorang diselamatkan, bencana tidak terjadi; bukti apa yang akan Anda cari?
MadHatter mendukung Monica

Dapat diperdebatkan, Anda juga harus memikirkan mode kegagalan cache tulis yang didukung baterai selain cache tulis tanpa baterai.
Stefan Lasiewski

1
Bukan jajak pendapat - Saya telah menghabiskan banyak waktu untuk menyelidiki hal ini - dan dapat menemukan banyak informasi tentang apa yang seharusnya dilakukan BBWC - tetapi sangat sedikit informasi tentang manfaat yang telah direalisasikan dalam praktiknya. Perhatikan bahwa satu-satunya respons yang saya miliki di bawah ini di mana seseorang mengatakan BBWC telah menyimpan data mereka adalah di mana tidak ada shutdown yang dikelola jika terjadi kegagalan daya. Sejauh ini tidak ada yang menyangkal kecurigaan saya bahwa: sementara BBWC dapat menyimpan data Anda dalam beberapa keadaan, keadaan ini mungkin dapat dihindari dengan cara lain.
symcbean

1
Tidak, itu bukti bahwa tidak memiliki BBWC dapat kehilangan data Anda . Membuktikan bahwa - dan saya menduga sebagian besar sysadmin jarak jauh pada sistem ini memiliki cerita di mana data volatile yang hilang dalam listrik padam; Saya tentu saja - tidak akan membuktikan bahwa memiliki BBWC dapat menyimpan data Anda , yang diminta OP.
MadHatter mendukung Monica

1
Beberapa analisis dan pemodelan lebih lanjut menunjukkan bahwa BBWC + tidak ada hambatan dapat menyebabkan korupsi tidak terdeteksi dengan penjadwal IO selain dari NOOP (saya bisa saja salah tentang hal ini tetapi telah berusaha sangat keras untuk menemukan bukti untuk menyarankan sebaliknya). Lihat juga symcbean.blogspot.co.uk/2014/03/...
symcbean

Jawaban:


34

Yakin. Saya memiliki cache yang didukung baterai (BBWC) dan kemudian cache tulis yang didukung flash (FBWC) melindungi data dalam penerbangan setelah crash dan kehilangan daya tiba-tiba.

Pada server HP ProLiant, pesan khasnya adalah:

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

Yang berarti, " Hei, ada data dalam cache tulis yang selamat dari reboot / kehilangan daya !! Saya akan menulis itu kembali ke disk sekarang !! "

Kasus yang menarik adalah post-mortem saya dari sistem yang kehilangan daya saat tornado , urutan arraynya adalah:

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

Kesalahan 1793 POST adalah unik. - Saat sistem sedang digunakan, daya terputus saat data berada dalam memori Array Accelerator. Namun, karena fakta bahwa ini adalah tornado, daya tidak dipulihkan dalam waktu empat hari, sehingga baterai array habis dan data di dalamnya hilang. Server memiliki dua pengontrol RAID. Pengontrol lain memiliki unit FBWC, yang bertahan jauh lebih lama dari baterai. Drive itu pulih dengan benar. Beberapa data menyebabkan array yang didukung oleh baterai kosong.


Meskipun banyak runtime baterai di fasilitas itu, empat hari tanpa daya dan kondisi berbahaya membuatnya mustahil bagi siapa pun untuk mematikan server dengan aman. masukkan deskripsi gambar di sini


5
Sangat informatif, pekerjaan yang bagus untuk menjaga hasil tersebut untuk waktu yang lama.
deed02392

Menarik! Saya ingin tahu apakah HP berencana untuk memasukkan dalam pengendali Smart Arrays cache bebas-baterai yang sama dengan yang mereka masukkan ke P2000
Gabriel Talavera

4
@GabrielTalavera Ya, HP telah menggunakan cache (kapasitor) yang didukung flash sejak 2010 atau lebih. Tidak ada lagi baterai.
ewwhite

Sama di sini menggunakan Adaptec;) Tidak ada lagi kekhawatiran dan penggantian reguler.
TomTom

Terima kasih ewwhite - persis hal yang saya cari. Satu pertanyaan: apa yang terjadi dengan daya UPS? Apakah UPS Anda tidak menurunkan sistem saat rendah?
symcbean

10

Ya, ada kasus itu.

Server "tanpa UPS" di pusat data (dengan pusat data memiliki UPS). Kegagalan PDU - sistem crash keras. Tidak ada kehilangan data.

Dan pada dasarnya itu. Hal yang baik tentang BBWC adalah ada di dalam mesin. Punya UPS - percayalah, kadang-kadang seseorang melakukan sesuatu yang bodoh (seperti menarik kabel yang salah). UPS adalah eksternal. Oh, kabel ITU;)


Terima kasih TomTom. Jadi itu memungkinkan Anda untuk menggulung maju data Anda ke penghalang berikutnya alih-alih menggulirnya kembali ke yang sebelumnya (kecuali jika Anda tidak menggunakan journalling atau log filesystem terstruktur). Ini adalah salah satu poin kunci yang saya coba nilai di sini. Tampaknya memberikan retensi yang sedikit lebih baik untuk peran fileserver, tetapi tidak membantu dengan integritas filesystem atau OLTP DB.
symcbean

Sebenarnya hal itu akan terjadi - OLTP disusun untuk menangani kegagalan daya server dengan anggun selama penulisan log ditulis secara akut;) Dan ketika kecepatan log IO terbatas, "penulisan palsu" (dilaporkan oleh dia menyerang pengontrol) memberikan kecepatan - tetapi dengan risiko kehilangan data, kecuali jika Anda memiliki cache yang tidak mudah menguap.
TomTom

Saya perhatikan bahwa RedHat berpendapat Anda harus menonaktifkan penghalang dengan BBWC - sementara itu akan meningkatkan kinerja, itu tidak memberikan perlindungan dalam hal pemadaman mendadak seperti kehilangan daya - erk! access.redhat.com/site/documentation/en-US/…
symcbean

@symcbean Anda seharusnya tidak kehilangan daya secara tiba-tiba di lingkungan Anda. Itu salah satu situasi yang paling mudah untuk dicegah. Mengapa server Anda berjalan seperti sampah 100% dari waktu untuk kejadian yang relatif jarang terjadi?
ewwhite

1
Sebenarnya alasan utama BBWC ada adalah untuk mengurangi masalah kehilangan daya yang tiba-tiba. Oleh karena itu tidak masalah untuk tidak memiliki hambatan.
TomTom

4

Saya memiliki 2 kasus di mana cache yang didukung baterai di pengontrol RAID HW gagal sepenuhnya (dalam 2 perusahaan terpisah).

BBC mengandalkan ide yang tidak mengejutkan bahwa baterai bekerja. Tangkapannya adalah bahwa pada titik tertentu baterai di controller gagal dan apa yang menghancurkan adalah bahwa dalam banyak pengendali serangan HW gagal diam-diam . Kami pikir kami memiliki cache yang dilindungi terhadap kehilangan daya tetapi kami tidak.

Pada kehilangan daya, kehilangan data array RAID sangat luas sehingga semua konten disk tidak dapat dipulihkan. Segalanya hilang. Salah satu kasus melibatkan mesin yang didedikasikan sepenuhnya untuk pengujian, tetapi tetap saja.

Setelah itu saya berkata "tidak pernah lagi", beralih ke disk mirroring (mdadm) berbasis perangkat lunak di Linux berbasis fs jurnal yang memiliki ketahanan yang layak terhadap kehilangan daya (ext4) dan tidak pernah melihat ke belakang. Memang, saya sudah menggunakannya di server yang tidak memiliki penggunaan IO yang sangat tinggi.


Terima kasih JD: walaupun tidak secara spesifik apa yang saya tanyakan tentang saya dapat melihat bahwa ini memiliki banyak relevansi dengan asumsi yang dibuat orang tentang BBWC. Itu beresonansi dengan banyak diskusi tentang perangkat keras vs perangkat lunak RAID, saya pikir saya harus membayar untuk keturunan bahwa perangkat lunak RAID tidak menghalangi penggunaan pengontrol caching (volatile atau sebaliknya).
symcbean

Kartu raid IME, Dell dan HP akan mengeluh (dengan asumsi Anda memiliki sistem pemantauan yang tepat) tentang baterai gagal dalam BBWC.
mfinni

Prosedur yang tepat untuk BBWC harus mencakup pengujian baterai - misalnya, pengontrol 3ware akan memperingatkan Anda jika baterai belum diuji selama beberapa waktu, dan mudah untuk menguji bahwa baterai masih sehat (satu-satunya downside adalah bahwa cache tulis dinonaktifkan selama tes).
iustin

4

Ini sepertinya memerlukan jawaban kedua untuk pertanyaan ...

Saya baru saja memiliki host VMware ESXi mandiri kehilangan drive dalam array RAID 5. Array yang terdegradasi memengaruhi kinerja pada level VM dan aplikasi.

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

Orang TI di perusahaan ini tidak menyadari bahwa drive gagal dan sulit mereset server ( untuk membuat semuanya lebih baik? ).

Efek menarik dari melakukan ini ke array yang dikompromikan dengan mesin virtual yang sibuk berjalan di atas adalah ini:

Rincian Status Cache: Pengontrol array saat ini memiliki data yang valid disimpan dalam cache tulis yang didukung baterai / kapasitor saat terakhir kali direset atau dinyalakan. Ini menunjukkan bahwa sistem mungkin tidak dimatikan dengan anggun. Pengontrol array telah secara otomatis menulis, atau mencoba menulis, data ini ke drive. Pesan ini akan terus ditampilkan hingga reset berikutnya atau siklus daya controller array.

Jadi meskipun sistem dihentikan tiba-tiba, data dalam penerbangan dilindungi oleh BBWC. Semua mesin virtual pulih dengan benar dan sistem dalam kondisi baik sekarang.


3

Selain "menyimpan data Anda", mereka bagus untuk hal-hal lain. Mereka juga pandai buffering write (dalam cache) untuk meningkatkan kinerja subsistem IO dengan menjaga disk-write-queue tetap rendah. Ini sangat penting untuk server di mana kinerja interaktif adalah yang terpenting - misalnya, Citrix XenApp atau Windows Terminal Services.

Ini kurang penting untuk server web, atau server file. Anda mungkin tidak memperhatikan, atau bahkan terbiasa, sedikit keterlambatan. Namun, ketika Anda mengklik ikon di aplikasi Office, Anda mengharapkan respons. Demikian juga CEO Anda.


"Saya kenal dengan apa yang ingin dilakukan BBWC (cache tulis yang didukung baterai)"
symcbean

2
Anda juga berkata: "Saya ingin tahu apakah itu benar-benar menawarkan manfaat nyata dalam praktik." Saya memberi Anda (dan pembaca masa depan) yang konkret. Dari pertanyaan Anda, sama sekali tidak jelas bahwa Anda tahu tentang manfaat ini. Dan jawaban saya tidak salah.
mfinni

Jadi, bagaimana perbedaan poin yang Anda buat dari cache tulis yang tidak stabil?
symcbean

Jelas itu adalah fitur yang Anda ketahui. Tetapi sekali lagi, Anda tidak menjelaskannya. @mfinni hanya membantu.
deed02392

Beberapa sistem tidak memungkinkan Anda untuk mengaktifkan cache tulis yang tidak stabil, jadi begitulah. Tapi tidak, jika Anda tidak peduli dengan data dan Anda dapat menggunakan cache tulis yang tidak stabil, maka lakukanlah.
mfinni
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.