Bir petabayt veri yedeklemenin ve saklamanın iyi bir yolu var mı?

Yüzlerce terabayt veriye sahip istemcileri görmeye başlıyorum (SQL Server kurulumlarında). Bazı işletmelerdeki toplam veri hacmi bir petabaytın anlamlı kısımlarına yaklaştıkça, bu büyüklükle uğraşan insanların onu korumak için neler yaptığını görmek için orada kolektif bilgi tabanını tuval haline getirmek istiyorum.

Açık olan sorun, bu kadar çok verinin birden fazla yedeklemesinin depolanmasının, işletme sınıfı depolama, heck, hatta sadece RAID-5 kullanarak oldukça pahalı olmasıdır.

Gördüğüm seçenekler şunlardır:

1. Başka bir veri merkezindeki verilerin ayna kopyasını oluşturun ve sürekli olarak farklılıklar gönderin (veri kaynağınız için mevcut olan herhangi bir mekanizmayı kullanarak (ör. Günlük gönderimi veya SQL Server ile veritabanı yansıtma)
2. Ağır bir sıkıştırma algoritması kullanarak düzenli yedeklemeler alın (muhtemelen yalnızca verilerin yoğun bir şekilde sıkıştırılmasına iyi bir şekilde katkıda bulunması durumunda uygundur )
3. Verilerin kritik / değişen kısımlarının parça parça yedeklerini alın.
4. Verileri yedeklemeyin ve yolsuzluk tanrılarına güvenmeyin.

Seçenek # 4'ün varsayılan olarak kabul edildiğini görüyorum ve bir HA / DR uzmanı olarak gerçekten korkutucu, ama alternatif olarak ne öneririm? # 1 en iyi yaklaşım olduğunu düşünüyorum, ancak # 4 ve muhtemelen # 3 dışında herhangi bir alternatif önerildiğinde "öyle düşünmüyorum" olağan cevaptır.

Şimdi, elbette verilerin değişim hızına ve kritikliğine bağlıdır. Microsoft'ta çalışırken SQL Server'ın tüm HA özelliklerinden sorumlu olduğum için buna cevap vermeye gerek yok, bu yüzden 'buna bağlı' argümanlarında iyi bilgim var - bu benim yakalama ifadem :-)

Kaçırdığım alternatifleri duymak ya da diğer herkesin aynı teknede olduğunu ve daha fazla depolamaya çok fazla para harcamak için gerçekçi bir alternatif olmadığını duymak isterim.

Şimdiden teşekkürler - iyi düşünülmüş ve ifade edilen tüm cevaplara kredi verilecektir.

Duvar dışı fikir - saklanan tüm bilgiler gerekli mi, hatta yararlı mı?

Bilginin gerçekte değeri nedir? Bakım ve yönetimde verilerin değerinden daha fazla harcama yapmak çok saçma görünüyor.

Veritabanındaki veriler bir veritabanında depolanmak için uygun mu? Örneğin, sıkıştırılmış çok gigabaytlık çekirdek dosyaları destek kuruluşunun veritabanında tutmak gerçekten herhangi bir fayda sağlıyor mu?

Veritabanında çok fazla yinelenen veri var mı? Örneğin, bin kişi haftalık 10 MB'lık bültenlerin her birinde on kopya alıyor mu?

Verilerin bazılarında "son kullanma tarihi" var mı, bundan sonra herhangi bir değer vermiyor mu? Destek kuruluşu örneğine dönersek, çeşitli nedenlerle, bir düzeltme teslim edildikten sonra birkaç aydan daha uzun bir süre boyunca müşteri çekirdek dosyalarının çevresinde tutmanın neredeyse hiçbir faydası yoktur.

Başka bir düşünce - şirketi borçlara açan bu kadar veriyi tutmaktır. Bazı veriler, yasa gereği saklanmalıdır. Ancak bazı veriler, yanlışlıkla veya kötü niyetli olarak uygunsuz taraflara yayınlanması durumunda ortaya çıkan riskler nedeniyle "parçalanmalıdır".

Evet, başka bir seçenek de depolama sanallaştırmasıdır: sunucularınız ve SAN arasında, IBM SVC gibi oturan bir aygıt. SVC SAN-SAN kopyalarını yönetir ve uzaktan çoğaltma yapabilir (ancak çok düşük veri değişim hızlarına ve gerçekten yüksek bant genişliğine sahip olmadığınız sürece petabayt düzeyinde oldukça acı verici olsa da).

Kaygan kısım, tüm sürecin ilgili sunucular için görünmez olmasıdır. SQL Server kullanıyorsanız, dosya gruplarınızı düşük değişim oranına sahip şeyleri (> 3 yıl önceki satış arşivleri gibi) ve yüksek değişiklik oranına sahip şeyleri (geçerli satışlar gibi) ayrı bir dosya grubunda tutacak şekilde tasarlarsınız. Tamamen salt okunur olmak zorunda değiller - sadece her dosya grubu için farklı çoğaltma yöntemleri kullanabilmeniz için tasarlamak istiyorsunuz. SAN dişli ağları ağ, bant veya SAN'lar aracılığıyla senkronize edebilir - yani SAN'ın parçalarını ileri ve geri gönderebilirsiniz. Bu, SAN'ın katılımcı birimler havuzundan oluştuğu LeftHand's gibi donanımlarda daha etkilidir.

Daha sonra düşük değişim oranı öğelerini tel üzerinden otomatik olarak senkronize edebilir ve yüksek değişim oranını sneakernet ile senkronize edebilirsiniz. (Bunu geriye doğru aldığım gibi görünüyor, ama bu doğru - yüksek değişim oranı şeylerini ses nedeniyle tel üzerinden senkronize edemezsiniz.) Düşük uçlu viteslerden bazıları bile şimdi bunu barındırıyor: LeftHand diğerlerine çoğalmanıza izin veriyor Veri merkezinizdeki LeftHand birimleri ve sonra bunları şirketinizin veri merkezinize gönderin. Takın, IP'leri ve grupları değiştirerek bunları uzak tarafa birleştirin ve şimdi bunlar uzaktan yedek SAN'ınızın bir parçası. Bu konuda LeftHand satış konuşması sadece harika: iki SAN'ınızı birincil veri merkezinizde yan yana kurun, senkronize edin, ardından bazı bölümleri güncel verilerinizde kalırken uzak veri merkezine gönderebilirsiniz. senkronize tutmak için veri merkezi. Yavaş yavaş hareket et '

Yine de bunu petabayt düzeyinde yapmadım. Ne dediklerini biliyorsunuz - teoride, teoride ve pratikte aynı. Uygulamada...

Seçenek 1, neredeyse # 4 kadar kötü olan yansıtmadır: verileri bozan ve hemen bulunmayan herhangi bir hata, her iki kopyayı da bozar.

Veriler kritikse, özel çözümleri düşünün; IBM'in Shark ürünleri veya EMS, vb. gibi rakip ürünler hakkında bilgi edinin. Flash gereksinimi, disk gereksinimlerini iki katına çıkarmadan dosyanın mantıksal bir kopyasını anında oluşturmanıza olanak tanıyan Flash-copy gibi özelliklere sahiptir; ve sonra bu kopyayı (ör.) banda yedekleyebilirsiniz. Robotik teyp yedeklemesine de bakın.

Depolamanın ucuz olmadığı bir Petabyte veri depolamak istediklerine dikkat edin.

Disk ucuz olduğu için ekstra bir Terabayt çevrimiçi depolama alanına sahip olmama konusunda inleyen insanlardan bıktım, çünkü disk ucuz olabilir, ancak cehennemde olmadığı için yönetilen depolama alanı.

Yedekleri depolamak aşırı derecede pahalıysa, verilerin güvenli bir şekilde saklanması yasak olarak pahalıdır, bu nedenle önerilen çözüm geçerli değildir.

Yedeklemenin en önemli nedenlerinden biri, kullanıcı hatasından korunmadır (çoğu donanım hatası sorunu donanım çözümleri tarafından ele alınabilir), ancak veritabanı aynalama bile bırakılan bir tabloya karşı koruma değildir (Tamam, buna karşı koruyabilirsiniz, ancak yine de DB'niz için çıkarılamaz guff almak mümkün - DB çok büyük olmadıkça sadece ekler sorunları olmasıdır).

Gördüğüm gibi, bant artık geçerli bir çözüm değil - artık sadece disk dizileriyle çalışmak daha ucuz (fiziksel depolama garip olabilir). Bu yüzden tek seçeneğiniz, verileri mantıklı bir zaman diliminde geri yüklenecek kadar küçük parçalara bölmenin ve daha sonra düzenli olarak disk depolama alanına almanın bazı yöntemidir (ve burada EMS tipi çözümler, nakit).

Myspace.com'un mimarisini (SQL2005 arka ucu) detaylandıran ilginç bir video. Birden fazla dbs ile ölçeklendirildiklerinden bireysel petabyte dbs olup olmadığından emin değilim. SAN ek yedeklerini kullanırlar.

http://wtv.watchtechvideos.com/topic70.html

ZFS. Elbette, henüz yeni başlıyor, ancak ZFS'nin sadece bu tür şeyleri ele almak için tasarlandığı birkaç alan var. Öncelikle, çok sayıda farklı veri depolama kapasitesinin yanı sıra çok sayıda farklı depolama cihazını (yerel, SAN, fiber vb.) İşleyebilme özelliği, verileri sağlama toplamları ile güvenli tutarken ve cihaz sağlığı ve başarısızlıkların. Yine de bu, bu kadar çok veriyi yedeklemeye nasıl yardımcı olur?

Bir yöntem anlık görüntüleri kullanmaktır. Anlık görüntü alın, uzak siteye aktarmak için bant / disk / net'e gönderin. Sonraki anlık görüntüler yalnızca gönderilen verileri gönderir ve gerekirse her iki uçta da canlı verileri saklayabilirsiniz.

Diğeri, (yeterince ağ bant genişliğine sahip olduğunuz sürece) iki sunucu arasında canlı bir yansıtma yapabileceğiniz ve birincisi düştüğünde ikinciyi devralabileceğiniz Solaris Cluster yazılımını kullanmaktır. Yüksek kullanılabilirliğin (HA) önemli olduğu yerlerde kullanmak için daha fazladır, ancak bu kadar fazla veriye sahip çoğu yerin HA istediği tahmin ediyorum.

Ve ZFS'nin sqlserver bulabileceğiniz olağan yer olan Windows'ta desteklenmediğini söylüyorsunuz, belki Sun / ZFS'yi arka uçta çalıştırıyor ve iSCSI üzerinden bağlanıyorsunuz. Belki de bu korkunç bir fikir, ama en azından biraz düşünmeye değer, böylece ne yapmamanız gerektiğini biliyorsunuz.

Bir seçenek olarak Amazon Buzulu'na baktınız mı?

IMO, eğer bir çeşit godzilla seviyesi donanımınız yoksa, bu kadar fazla veriye sahipseniz, bir yedekleme sıkıştırma teknolojisi kullanmalısınız. LiteSpeed'i en iyi biliyorum, ancak diğer satıcılardan benzer ürünler var ve (tabii ki) benzer bir özellik SQL2008'de yerleşiktir. 10'a 1 sıkıştırma alamayabilirsiniz, ancak yedekleme için depolama gereksinimlerini azaltır ve ayrıca yedekleme penceresi gereksinimlerinizi daraltabilir. Amacınız birden fazla yedekleme kümesi tutmaksa (dün artı ondan önceki gün, artı geçen haftadan ve geçen aydan bir tane veya bir dizi diferansiyel artı dolu tutmak, eğer çok fazla veri değiştirirseniz çok büyük olabilir veritabanı), basit bir depolama alanı meselesidir.

Dosya grubu tabanlı yedekleme (IOW, belirli FG'lere uçucu olmayan veriler koyun ve sık sık yedekleme yapmayın) hiçbir zaman uçmuyor gibi görünmüyor çünkü geliştiriciler veya kullanıcılar hangi verilerin değişken ve neyin olmadığına ve brownfield'a karar veremiyor veya veremiyor genellikle risk alamayacağınız senaryolar.

Yük devretme sitesi bir gereklilikse, Veritabanı Yansıtması'nı düşünmenin yanı sıra) donanım tabanlı bir veri çoğaltma teknolojisi olan SRDF gibi bir şey sunup sunmadıklarını görmek için müşterilerinizin depolama sağlayıcısıyla konuşmak isteyebilirsiniz. Doğal olarak, çoğaltma (herhangi bir tür, ancak özellikle gerçek zamanlı veya gerçek zamanlıya yakın çoğaltma) yedeklerin yerini tutmaz.

Burada v / disk kasetinde çok fazla seçeneğiniz olduğunu düşünmüyorum. Bant, şeritlemediğiniz sürece normal bir yedekleme penceresinde kesmez ve güvenilirliğin orada olduğundan emin değilim.

Böylece disk yedeklemelerine düştünüz. Sürüm oluşturuyor musunuz? 2 yedeklemesine (şu anki db eksi 2 yedeklemeleri) geri dönme konusunda endişe duyuyor musunuz? Veya yedek 3? Bu durumda, sorunlarınız olabilir, ancak büyük olasılıkla işlemek zorunda olduğunuz günlük yedeklemeleri, çok fazla veri yedeklemesi değildir.

Bazı verileri salt okunur / değişmez olarak bölebilirseniz, yönetilebilir yedekleme boyutlarınız / pencereleriniz olabilir. Ya da en azından yedekleme teknolojisinin ve bant genişliğinin veri büyümesini yakalamasını umuyorsunuz.

Birincil ile ilgili sorunlardan kurtulmak için 2. kopyayı sakladığınız kadar yedekleme yaptığınızı sanmıyorum. Bu, donanım, bozulma vb. Anlamına gelir ve günlük olarak hataların ikinci kopyaya gönderilmemesi için dua edersiniz. Kopyalar büyük ihtimalle snap-shot'ing teknolojisi ile SAN-SAN olarak üretiliyor. orijinal kopya tel üzerinden değil, Fed-Ex üzerinden olabilir. 100 TB taşımak için bant genişliği hiç kimse için kolay değildir.

Mükemmel günlük yedekleme yönetimi ile 1, 2 ve 3 (4 değil) kombinasyonuna ihtiyacınız olduğunu düşünüyorum.

Aslında, herhangi bir zamanda verilerinizin 3 kopyasına gerçekten baktığınızı düşünüyorum. Değişiklikleri almak için 2. kopya kullanılırken kopyaların 1'inde CHECKDB çalıştırılıyor. Sonra 2. kopyayı ilk görüntüye alıp devam edersiniz. Bu kadar veriyle, burada biraz titizliğe ihtiyacınız olacağını hayal ediyorum. Paul, checkdb çevrimiçi olan çok kullanıcılı, 100 TB db'de nasıl çalışır?

Belirtildiği gibi, günlük yedekleri ve muhtemelen bir günlük okuyucu kritik değil mi? Yedekleme yerine günlüklerden açılan tabloları / kullanıcı hatasını kurtarmanız gerekmez mi? SAN kopyalarını biraz gecikmeyle göndererek buna kısayol yapabilirsiniz, ancak bu teknolojiyi görmedim. Verilerin üzerine yazmadan önce sorunları gidermenizi sağlamak için değişiklikleri 4 saat (veya belirli bir aralıkta) geciktirebilen bir Log Shipping SAN. Ya da SAN-blok-değişikliklerinin bazı günlük okuyucuları? Bu olmadan, ölümcül olmayan hatalardan potansiyel olarak kurtarmanıza izin vermek için çeşitli dosya sistemlerinde bu yedekleri birkaç saat boyunca izlemenin başka bir seviyesi olabilecek bu işlem günlüklerini yönetmeniz gerekir.

Teknik olarak, depolama olduğunu ucuz ama petabaytlık düzeyinde, pek değil. Gerçekten uygulamaya bağlıdır, ancak # 2 ve # 3 stratejisinin bazı kombinasyonlarının cevap olacağını söyleyebilirim, # 2 a ve # 3, depolamada ne kadar yatırım yapabileceğinize ve türüne bağlı olarak depolama ve IO / hesaplama gücü, mümkün olduğunca az artımlılık ve mümkün olduğunca gizli, tam yedeklemeyle kurtulmanızı sağlar.

Alternatif olarak, bant genişliğinize ve verilerde ne kadar değişiklik olduğuna bağlı olarak Amazon S3 gibi bir şey de devreye girebilir - bu ciltte, en azından bir kısmını başka birinin sunucularına koymak ve artıklık konusunda endişelenmelerine izin vermek gittikçe daha fazla olur uygun maliyetli.

Depolama sağlayıcınızla konuşun, daha önce kullandıkları bir veri tekilleştirme ürününe sahip olacaklar, düzenli sıkıştırma ile birlikte veri ayak izinizi genellikle% 70 oranında azaltabilirsiniz. Tabii ki bir petabayt depolama için harcayacak parası olan herkes de iyi bir yedekleme çözümü satın almak için bütçeye sahip olabilir - eğer o zaman onlar değil sadece onlara o petabayt kaybetme işlerini mal olacağını sormak gerekir.

Büyük bir kurumsal veri deposunda, verilerin çoğu zaten yedeklenmiş kaynaklardan gelir. Teradata ve ODW kurulumlarında # 4 seçeneğini aldıkları yerlerde çalıştım, ancak bir veya iki gün işlem verisini geri yükleyebileceklerini ve kaynak sistemlerden dönüştürebileceklerini biliyordum.

Bir perakende müşteride (dünyanın en büyük 5 DW'sından birine sahip olduklarında, yaklaşık 200 TB'da ... bunun ne kadar önce olduğuna dair bir fikir verir), yeni bir Petabyte satın aldıktan sonra # 1 seçeneğiyle gittiler. sınıf Teradata sunucusu. Eski düğümler önceki günün sisteminin anlık görüntüsü için kullanılırken, yeni düğümler mevcut olanı korudu. Bu, yük devretme perspektifinden de güzeldi - her seferinde bakım için her şeyi aşağı çekiyorlardı ve sadece eski yavaş sunucuyu günlük verilerle kullanmaya başlıyoruz.

Dürüst olmak gerekirse, her şeyi devam ettirmek için işleme / depolama / vb.