Gücü rastgele kesilen bir makinede veri nasıl saklanır

13

Fiziksel bir makine ana bilgisayarında çalışan bir sanal makinem (Debian) var. Sanal makine, yerel ağ üzerinden sık sık aldığı veriler için bir tampon görevi görür (bu verilerin süresi 0,5 saniyedir, bu nedenle oldukça yüksek bir verimdir). Alınan tüm veriler sanal makinede saklanır ve tekrar tekrar UDP üzerinden harici bir sunucuya iletilir. Harici sunucu bir veri paketi aldığını (UDP üzerinden) kabul ettiğinde, orijinal veriler sanal makineden silinir ve tekrar harici sunucuya gönderilmez. Sanal makineyi ve harici sunucuyu bağlayan internet bağlantısı güvenilir değildir, yani bir seferde günlerce kapalı olabilir.

VM'yi barındıran fiziksel makine, gücünü günde birkaç kez rastgele keser. Bunun ne zaman gerçekleşeceğini anlamanın bir yolu yoktur ve sisteme UPS, pil veya benzer bir çözüm eklemek mümkün değildir.

Başlangıçta, veriler sanal makinedeki dosya tabanlı bir HSQLDB veritabanında saklanmıştır. Ancak, sık sık elektrik kesintileri sonunda veritabanı komut dosyası bozulmasına neden olur (dosya sistemi düzeyinde değil, yani okunabilir, ancak HSQLDB bunun mantıklı olamaz), bu benim soruya yol açar:

Veriler, elektrik kesintilerinin sık olabileceği ve olabileceği bir ortamda nasıl saklanmalıdır?

Düşünebileceğim bir seçenek, her veri paketini dosya sisteminde bir dosya olarak kaydederek düz dosyalar kullanmaktır. Bu şekilde bir dosya güç kaybı nedeniyle bozulursa, yok sayılabilir ve verilerin geri kalanı bozulmadan kalır. Ancak bu, esas olarak sanal makinede depolanması muhtemel veri miktarı ile ilgili birkaç sorun ortaya çıkarmaktadır. Her veri parçası arasında 0,5 saniyede 10 günde 1.728.000 dosya oluşturulacaktır. Bu, en azından bu verileri depolamak için artan sayıda inode içeren bir dosya sisteminin kullanılması anlamına gelir (mevcut dosya sistemi kurulumu ~ 250.000 mesajdaki ve kullanılan% 30 disk alanındaki düğümlerden bitti). Ayrıca, yönetilmesi zor (imkansız değil).

Başka seçenek var mı? Debian üzerinde çalışan ve elektrik kesintilerinden dolayı bozulmayacak veritabanı motorları var mı? Ayrıca, bunun için hangi dosya sistemi kullanılmalıdır? şu anda kullanılan ext3.

Sanal makinede çalışan yazılım Java 6 kullanılarak yazılmıştır, bu yüzden umarım çözüm uyumsuz olmaz.

debian filesystems corruption

— Sevas
kaynak

14

"VM'yi barındıran fiziksel makine, günde birkaç kez rastgele güç kesintisi yapıyor. Bunun ne zaman gerçekleştiğini anlamanın bir yolu yok ve bir UPS, pil veya benzer bir çözüm eklemek mümkün değil. sistemi." Bunun nasıl mümkün olduğunu gerçekten bilmek istiyorum. Uluslararası Uzay İstasyonunda mı, UPS göndermek için 20 milyon dolar mı gerekiyor?

— ceejayoz

3

Makinede en az pil destekli önbelleğe sahip bir RAID denetleyicisi var mı?

— Zoredache

4

Bu soruna çok ilginç, yaratıcı ve teorik olarak doğru çözümler önerebiliriz. Bununla birlikte , ana bilgisayarda hangi hipervizör ve donanımın çalıştığını bilmiyoruz, bu yüzden disk yazmaların gerçekten yazıldığını veya doğru sırada yazıldığını garanti etmez ...

— pino42

5

@Sevas Kulağa gelmiyor gibi görünüyor, ancak 50 temel, ucuz UPS'in 2500 dolara mal olacağını ve bakıma ihtiyaç duymadığını belirtmeye değer. ). Yazılımda bunu çözmeye çalışmanın maliyeti, ücretsiz çalışan bir grup kodlayıcı bilmiyorsanız, bundan çok daha yüksek olacaktır. Düzinelerce veya yüzlerce yetenekli adam saat yerine 3 saatte bir saat yerine, 50 $ / birim karşılığında bu sorunu çözmek için yönetim almak faydalı olabilir.

— HopelessN00b

9

Bu aslında kötü niyetli bir program gibi geliyor. Kullanıcı "VM" nin bilgisayarında çalıştığını bilmiyor. Tüm ağdaki verileri çalıyor - daha sonra kendisini gizlemek için tek bir bağlantı üzerinden aktarıyor. Kullanıcı bilgisayarı "rastgele kapatıp açar" - böylece bir UPS ekleyemezsiniz.

— Laurence

23

Dürüst olmak gerekirse, buradaki en iyi yaklaşımınız elektrik kesintilerini düzeltmek veya daha iyi bir yere farklı bir sistem kurmaktır.

Evet, yeniden oynatma için verileri yalnızca ek günlüğüne depolayacak redis gibi sistemler vardır, ancak daha düşük düzeylerde bozulma riskiyle karşı karşıya kalırsınız - örneğin dosya sisteminiz karıştırılmışsa, diskteki veriler potansiyel olarak risk altındadır.

Herhangi bir iyileştirmenin sizin için yararlı olacağını takdir ediyorum, ancak gerçekten sorun, özetlediğiniz senaryo göz önüne alındığında çözülebilecek bir sorun değildir.

8

+1 Doğru cevap "Bunu yapma"

— Chris S

6

+1 Sonunda rastgele elektrik kesintileri dosya sisteminizi bozar. Elektronikleri, güçleri kesilirken beklenmedik şeyler yapar.

— Grant

-1 (sanal -1). Bence böyle bir sistem elektrik kesintilerinin zaman zaman meydana geldiği varsayımı üzerine kurulmalıdır . Bu varsayım, uğraşmanız gereken gerçek bir dünya gerçeğidir.

— Igal Serban

11

Yaklaşımınız işe yarayabilir. Bazı iyileştirmeler önereyim. Dosyaya atomik yazımda yığın taşmasında bir soru vardı . Temel olarak, her veri paketini geçici bir dosyaya kaydedersiniz ve ardından son adına yeniden adlandırırsınız. Yeniden adlandırma, elektrik kesintilerinden korunacak bir atomik işlemdir. Bu şekilde, son hedefinizdeki tüm dosyalarınızın bozulmadan sorunsuz bir şekilde kaydedildiği garanti edilir.

Sonra milyonlarca dosyaya sahip olma sorunu ile başa çıkmak için ne yapabilirsiniz. Cron, belki de her saatte bir saatten daha eski olan tüm dosyaları çalıştıran ve bu işi bir elektrik kesintisi sırasında bile güvenli bir şekilde çalışacak şekilde eski bir dosyayı silecek şekilde yeniden atomik dosya işlemleri kullanarak birleştiren bir iştir. Günlük dönüşü gibi. Saatlerce dosya yaklaşık 7.200 dosya olacaktır. Bu nedenle, herhangi bir zamanda diskte 20.000'den fazla dosya olmamalıdır.

— Marwan Alsabbagh
kaynak

1

Kötü bir cevap değil, ama onunla ilgili sorun, yazmanın kendisinin atomik bir işlem olduğunu varsaymaktır, ki bu değildir. Bu nedenle, yanlış zamanda bir elektrik kesintisi yine de veri veya FS bozulması oluşturabilir. Muhtemelen gücü sabitlemek veya bir UPS'e takmak için en iyi seçenek hakkında, ancak +1.

— HopelessN00b

@ HopelessN00b yeniden adlandırma atomik bir işlem olacak, bu bir POSIX gereksinimi

— Marwan Alsabbagh

Evet, dosyayı yazıldıktan sonra yeniden adlandırmak atom işlemidir. Dosyayı ilk etapta yazmak değil.

— HopelessN00b

3

@ HopelessN00b Yeni dosyanın yarı yazılı veya bozuk olması önemli değil. İyi durumda olan eski dosyanız var. Sistemi kurtardığınızda, yarı yazılmış dosyayı yok edersiniz.

— DJClayworth

2

@ HopelessN00b Kesinlikle! sadece geçici bir dizindeki geçici dosyaların yarıya kadar yazılabileceğini söyler. Son hedef dizininizdeki tüm dosyalar her zaman

— bozulmayacak

7

Sisteme bir pil destekli yazma önbelleğine sahip bir UPS veya RAID kartı takıyorsunuz ve 49,95 $ kadar bir ücret karşılığında , yalnızca yazılımda başarılması imkansız olanı başarıyorsunuz.

Bu sunucuyu bir UPS ya da bataryaya bağlamanın bir şekilde mümkün olmadığı iddianız ... inandırıcı değil.

— HopelessN00b
kaynak

9

Bürokratik aptallık her zaman inanılır.

— Dan is Fiddling by Firelight

3

@DanNeely My PHB won't let me hook this up to a UPS/battery, it is not possible to add a UPS, a battery, or a similar solution to the system. çok bilgiçlikten kaçmamaktan çok farklı bir şeydir , ancak önemli bir ayrımdır çünkü mevcut yaklaşımı ve çözümleri değiştirir.

— HopelessN00b

Veya başka bir yerde de belirtildiği gibi, kaçırılmış bilgisayarın kullanıcısı bir UPS kurmamı istersem şaşırırdı. Durum başka türlü biraz inanılmaz. Herhangi bir sebeple, herkes uygun iş durumu göz önüne alındığında bozuk veriler üzerinden bir UPS'i kabul eder.

— WernerCD

@WernerCD CIO'muzla tanışmanızı istiyorum. Birinin bilgisayarını ele geçirmenin bunun olası bir kullanım örneği olduğunu kabul etsem de, meşru olanları da düşünebilirim, bu yüzden adama şüphenin yararını vereceğim. Gömülü sistemleri ve denetleyicileri ya da bir Raspberry Pi gibi düşünün - kullandığınız "bilgisayarın" bir UPS'e bağlanması gereken 50 $ 'dan daha düşük bir değere sahip olması muhtemeldir.

— HopelessN00b

Bilgisayar 50 $ 'dan az olsa bile - bilgisayardaki veriler aslında bir şeye değer. Google, "değersiz" bilgisayarlar üzerine kurulmuştur. CPU'nun maliyetinden daha önemli olan kayıp veri maliyeti, kayıp insan gücü (Bu programlama macerası, veri bozulması peşinde, eski sistemde hata izleme ve bu yeni kısım), müşteri değeri kaybı (Verilerimi mi kaybettim?) Sonraki şirket lütfen.), Vb.

— WernerCD

5

Tüm verilerinizi saklayan bir blok cihazı hariç, sistemin tamamını salt okunur olarak bağlayın. Bu engelleme cihazını doğrudan kullanın ve bu ham engelleme cihazını kullanarak kendi veri depolama mekanizmanızı uygulayın.

— MikeyB
kaynak

3

... pil destekli bir disk denetleyici kartına yatırım yapın ve diskte yazma önbelleği olmadığından emin olun, ya da vidalısınız.

— voretaq7

Düz dosya çözümleri ile kullanılan bazı katı hal depolama ile bir Live-CD veya eşdeğer ROM sisteminden önyükleme yapmaları gerektiğini söylemek için buraya geldim.

— Mark Allen

Yazma önbelleği devre dışı bırakılabilir. Bu yaklaşım uygulanabilir. Yalnızca ekleme Depolama mekanizması tavsiye edilir. Bloklar atomik olarak yazılır (sanırım), yeni / yapılacak verilerle bölümün başlangıcına ve sonuna işaret eden iki "işaretçi" bloğunuz olabilir. İşaretçiler veri yazıldıktan / tamamlandıktan sonra güncellenir. NCQ da devre dışı bırakılmalıdır.

— sleeplessnerd