Oracle veritabanı için önerilen RAID yapılandırması nedir?


16

RAID (Ucuz Disklerin Yedek Dizileri) farklı yapılandırmalarla (RAID-0, RAID-1 ...) birlikte gelir. Bir Oracle veritabanı kurarken kurmam ve kullanmam gereken önerilen RAID yapılandırması nedir? Veritabanı esas olarak bir veri ambarı olarak kullanılacaktır.


RAID0 ve RAID1 tamamen farklı şeylerdir. RAID0'ı yalnızca performans için ve RAID1'i yalnızca sürücü arızası durumunda hata toleransı için kullanırsınız.
Jonas

4
RAID0 asla bir veritabanı sunucusunda kullanılmamalıdır. Tabii ki banttan geri yüklemeyi sevmediğiniz sürece.
mrdenny

Yanıtlar:


13

Değişir. Bir veri ambarına bakarken, belirli bir tasarımınız yoksa, otomatik depolama yönetimi mükemmel bir rota olabilir.

AskTom , OTN Forumları , OTN Forumları 2 ve OTN Forumları 3'teki tartışmayı düşünün .

Bir şeylerle başa çıkmak için doğru bir yol yoktur ve cevaplar bir dizi donanım ve ağ faktörüne göre değişir. Kendinizi keşfetmek için, ASM tabanlı bir makineye, Raid'in linux tarafından sanallaştırıldığı bir SAN'a ve donanım tabanlı bir baskın makinesine örnek bir veri ambarı (yalnızca bir veya iki konser, oynamak için yeterli) önceden yükleyin.

Her üç ortamdaki sorguların sonuçlarını zamanlayarak, performans açısından sizin için en iyi olan metodolojiyi keşfedebilirsiniz. ASN ve linux tabanlı sanal baskınları kullanarak veritabanları dağıttım ve sanal bir baskın biraz daha iyi davrandı (birkaç yıl önce). Ancak, bunun kısmen sürücülerin kurulum şekline benzediğinden şüpheleniyorum.

Tekil doğru cevap yoktur. Boyut ve performans gereksinimleri hakkında bize daha fazla ayrıntı sağlayabilirseniz, çeşitli test senaryolarını keşfetmek mümkün olabilir.

--Düzenle--

Her " disk grubu ", uygun alt sistemdeki bir veya daha fazla disk, dizin veya dosyadan oluşabilir. Oracle önerir "en iyi performans ve güvenilirlik için bir RAID aygıtı veya birden fazla fiziksel cihaz üzerinde mantıksal hacim seçip şerit-ve-ayna-herşey (AYNI) metodolojisini uygulamak." dosyaları bir dosya sistemine yerleştirirken. Bu, kehanet RAID 1 + 0'ı öneriyormuş gibi okunur.

Ancak ASM tarafından yönetilen disk grupları, "İki yönlü yansıtma kullanıyorsanız, normal bir yedekleme diski grubu en az iki hata grubu (veya iki disk aygıtı) gerektirir. Normal bir yedekleme diski grubundaki etkin disk alanı, toplamın yarısı kadardır. tüm cihazlarındaki disk alanı "görünürde otomatik olarak yansıtma sağlar.

Bu aygıtların kendileri RAID aygıtlarından oluşabilir. RAIDed veri ambarları kurarken yaptığım pratik testlerde, dosya sistemindeki basit bir sanal RAID 5 kabul edilebilir performans sağladı ve ek ASM hiçbir performans avantajı sağladı. Bu tür bir optimizasyon görevinde, önce kaynaklarınızı tanımlayın ve ardından olası her yapılandırmayı test edin, çünkü bazen sonuçlar aşırı derecede sezgisel olabilir.


1
Sanal baskın oldukça komik geliyor: /
jcolebrand

10

İki fiziksel sürücünüz varsa:

RAID0: Hızlı, ancak artıklık yok. Herhangi bir sürücü hatası tüm diziyi öldürecektir. Bazı insanlar RAID0 (yani MSSQL altında tempdb) geçici depolama koymak ama yine de dizi düşerse durumu onarılan bir sunucu kesintisi olacak eğer herhangi bir anlamlı veri kaybetmeyecek gibi bu tehlikeli düşünün.

RAID1: İki sürücünüz varsa bunun için gidin. İyi bir denetleyici ile okuma performansının arttığını görebilirsiniz, ancak yazma performansı avantajı yoktur. RAID1'in temel özelliği, ölen sürücülerden birinde hayatta kalmaktır.

Üç fiziksel sürücünüz varsa:

Seçenekleriniz, destekleniyorsa standart olmayan 3 sürücülü RAID10 (veya IBM denetleyicilerinin belirttiği RAID1E) olan RAID5'dir. Elbette RAID1'i kullanabilir ve diğerlerinden biri arızalandığında ekstra sürücüyü yedek olarak tutabilirsiniz, ancak yine de kritik bir ortamda yedek parça tutmalısınız, bu yüzden söylemeye gerek yok.

RAID5, RAID10'dan (bir buçuk yerine iki sürücü değerinde) daha fazla alan sunar, ancak denetleyicinin yazılan her blok için eşlik bloğunu okuması, güncellemesi ve geri yazması gerektiği gibi potansiyel bir yazma performansı sorunu vardır. Her yazma için en az iki yazma olduğundan veritabanı yazma işlemleri için bu yazma performansı sorunu ikiye katlanabilir: biri işlem günlüğüne ve diğeri de gerçek veri alanlarına. Günümüzde alan ucuz olduğundan, daha iyi yazma performansı için destekleniyorsa 3 sürücülü RAID10'u öneriyorum. Linux'un yazılımı RAID, birçok IBM denetleyicisi gibi (RAID1E olarak adlandırılır) bunu sunar. Standart bir düzenleme olarak kabul edilmediğinden, standart bir ada sahip olmadığı için diğer adlar altında da bulabilirsiniz.

Hem R5 hem de üç üzeri R10 aynı yedekliliği sağlar (herhangi bir sürücü bir seferde başarısız olabilir ve dizi hayatta kalacaktır) ve benzer okuma performansı metrikleri (iki sürücülü bir RAID0 dizisine benzer).

Dört fiziksel sürücünüz varsa:

Yalnızca bir dizi oluşturuyorsanız, iki seçenek vardır (etkin yedek "varyasyonlarıyla" yoksayılıyor): RAID6 ve "geleneksel" RAID10 (RAID1'lerin RAID0'ları).

Her ikisi de aynı alanı verir (dördünüzün iki sürücüsü). RAID10, olası iki sürücünün gittiği altı durumdan yalnızca dördünde hayatta kalabildiği için herhangi bir iki sürücünün arızalanabileceği için RAID6 daha iyi yedeklilik sağlar. Her ikisi de simialr okuma performansı sağlar, ancak RAID6'nın RAID5'lere benzer bir yazma performansı sorunu vardır (iyi bir denetleyicide aynıdır, ancak kötü bir denetleyicideki RAID5'ten veya işletim sistemine bağlı bir G / Ç kontrol özelliklerine bağlı olarak RAID yazılımından daha yavaş olabilir. genellikle performans nedenleriyle veritabanları için tercih edilir - fazladan yedeklemeye ihtiyacınız varsa altı sürücü kullanabilir ve bir RAID0 veya 2 3 sürücülü RAID1'e sahip olabilirsiniz.

Dört veya daha fazla sürücünüz olduğunda, ayrı bir RAID1 dizisine sahip olabileceğiniz için işler daha ilginç hale gelir. Bu, veri depolarınızı bir dizide tutarak ve işlem günlüklerini başka bir dizide tutarak eğirme diskleri ile önemli performans avantajları sunabilir - bu, bazı durumlarda kafa hareketlerini önemli ölçüde azaltabilir ve "rastgele" erişim nedeniyle arama sürelerini gerçek bir performans katilidir. Bir veri ambarı için, bunun göreceli olarak çok az sayıda yazma göreceği anlamına gelir, işlem günlüklerini veri dosyalarından ayırmak daha sınırlı fayda sağlayabilir, ancak yine de birden çok diziyi düşünmek ve bunun yerine verilerinizi potansiyel olarak daha iyi okuma performansı için bölümlemek isteyebilirsiniz .

Dörtten fazla sürücünüz varsa:

Burada seçenekler tamamen açık hale gelir ve bu gerçekten verilerinizin ne olduğuna ve beklenen güncelleme / okuma yükleri / kalıplarının ne olduğuna bağlıdır. Örneğin, hizmetlerimizden biri 12 ~ 70Gb sürücülerde çalışır:

  • Sistem alanları için 4x RAID10 (OS, SQL Server (bizim durumumuzda MSSQL), takas, tempdb).
  • Veri dosyaları için RAID10 olarak 4x
  • İşlem günlükleri için RAID10 olarak 4x

Tempdb sistem dizisinde tutulur. Diğer iki diziye taşıyabilir ve sistem dizisini RAID1'de 2 sürücü olarak çalıştırabiliriz, çünkü sistem parçaları için ekstra hız çok gerekli değildir (çünkü önyükleme sırasında veya takas sırasında gerçekten önemlidir ve asla takas etmek için yeterli RAM), ancak bu makine seti için barındırma sağlayıcısını ödeme yöntemimizle, iki sürücüyü düşürmek için bize daha az mal olmazdı. Yedeklemeler ayrıca sunucu dışı, site dışı ve çevrimdışı yedekleme konumlarına kopyalanmadan önce sistem dizisine gider.

Tabii ki bu bazı veritabanları için ciddi bir şekilde abartılıyor (küçük bir blog sunucusunu bu şekilde çalışmanın bir anlamı olmaz!) Ancak ana uygulamamız bu düzenleme ile çok iyi bir performans sergiliyor.

Altı sürücünüz varsa, üç RAID1 dizisini veya iki üç sürücülü RAID10 dizisini düşünebilirsiniz.

genellikle

Maalesef, sisteminizin boyutuna ve kullanım şekillerine çok bağlı olduğundan, gerçek bir basit "en iyi uygulama" yoktur. Düşünebildiğim veya yapabileceğim tek genel kural:

  • yazma performansı sorununun sizi önemli ölçüde etkilemeyeceğini bilmiyorsanız RAID5 ve 6'dan kaçının
  • dört veya daha fazla dönen disk tabanlı sürücü ile kafa hareketlerini azaltmak için işleri birden fazla diziye ayırmayı düşünün (dikkate alınacak fiziksel kafa hareketleri olmadığından, birden fazla dizinin tam faydası iyi SSD'ler için geçerli olmayacaktır, ancak SSD'lerin denetleyicisinin yazma birleştirme stratejisi vb.)
  • test edin, test edin ve tekrar test edin: seçtiğiniz düzenlemenin gerçekten en uygun olduğunu doğrulamak için zaman bulmaya çalışmak her zaman iyidir

Donanım veya Yazılım RAID?

Eşlik hesaplamaları ve sürücüler ile CPU arasındaki yavaş arabirimler nedeniyle yapılan tüm düzenlemeler için RAID yazılımının performansının RAID 5 için donanım RAID'inin altında olmasıydı. Modern CPU'larda parite kireç sorunu gerçekten bir sorun değildir, ancak çok hızlı sürücülere sahipseniz, sürücülerin toplam hızı herhangi bir yere gelebiliyorsa donanım RAID yine de kazanabilirmakinenin disk denetleyicisiyle ne kadar hızlı konuşabileceğine yakın (büyüklük sırasına göre, bir tahminle). Yazılım RAID ile dört sürücülü bir RAID1 diziniz varsa (örn. Çok fazla yedeklilik için aynı verilerin dört kopyası), her yazma işlemi işletim sisteminin I / O denetleyicisine, muhtemelen bir donanımla birlikte dört lot veri göndermesiyle sonuçlanır. OS sadece bir yazma isteği gönderir ve kontrolör bunu muhtemelen dört sürücüye paralel olarak gönderir.

İyi donanım RAID'in başka avantajları da olabilir: bazı yüksek özellikli denetleyicilerin pil yedeklemeli yazma önbelleği vardır, böylece UPS'iniz arızalansa bile bekleyen yazma işlemleri güç kesintisinde kaybolmaz.

Yazılım RAID'i daha ucuz ve daha taşınabilirdir, bu nedenle denetleyicileri / makine arızası nedeniyle dizileri taşımak zorunda kalırsanız belirli bir denetleyiciye bağlanmazsınız.

Ucuz donanım RAID genellikle yazılım ve donanım RAID negatiflerini birkaç avantajla birleştirir (veya bunların hiçbirini kullanmaz).

Yazılım geliştirici, test ve UAT sunucularımızda RAID ve canlı müşteri / halka açık hizmetler çalıştıran sunucular için iyi donanım RAID'i kullanma eğilimindeyim.


5

" Oracle Veritabanı Performans Ayarlama Kılavuzu " nun G / Ç Yapılandırmasına ayrılmış bir bölümü vardır . Kısacası:

  • Çizgi kullanın (donanım RAID, yazılım RAID, ASM)
  • RAID5'i Arşivleme ve günlükleri yinele için kullanmayın
  • Dosya Sistemi blok boyutunu ve DB blok boyutunu hizalama

4

Bazı durumlarda JBOD doğru cevaptır (yani RAID değil ).

Sorun, çok büyük RAID gruplarınız varsa, fiziksel depolama alanının veritabanında nasıl düzenlendiğini belirleme esnekliğine sahip olmamanızdır; örneğin, bir tablo için dizinlerin ve kayıtların ayrı iğlerde depolandığından emin olma, ve tüm disklerinizdeki yazma işlemlerini dengelediğinizden emin olun.

Yazmaları dengelemek için şeritleme (RAID0) kullanabilirsiniz, ancak hepsi büyük bir grupsa dizinleri ve kayıtları ayıramazsınız.

Yansıtma (RAID1) hataya dayanıklıdır ve okumalar için daha hızlıdır (hangi iğ meşgul değilse okuyabilirsiniz), ancak her iki kopyanın da yazılmasını beklemeniz gerektiğinden yazma işlemleri için daha yavaş olabilir.

Ben asla bir veritabanına RAID5 veya RAID6 gitmek değildir. Veriler önemliyse, daha fazla disk satın alın ve RAID1 ile devam edin; RAID5 / 6 yavaştır (özellikle yazılımda) ve günümüzün sabit disk boyutlarının büyük bir disk grubu için başarısız diskleri değiştirdikten sonra yeniden oluşturulması günler sürebilir ... çoğu RAID5 / 6 sisteminin eşlik hatalarıyla başa çıkma şeklinin pariteyi yeniden hesaplamak için ... ama olasılıklar, hata verilerde, parite değil, hatanın nerede olduğu hakkında hiçbir fikriniz yok. (ne yazık ki, veritabanları için LOCKSS gibi bir şey olduğunu düşünmüyorum)

...

Veritabanında gördüğüm en ilginç düzen aslında iğ başına iki bölüme sahipti - diskin en iç kısmı üretim veritabanı için kullanıldı, diskin üst bölümleri yedeklemeler için kullanıldı. (ve bir bölümün aynı iş miline yedeklenmediğinden emin oldular; Sanırım birden çok veritabanı vardı, bu yüzden her biri farklı bir diskten yedeklendi). Bu, onlara iş günü boyunca daha fazla iğde bir şeyler yayma avantajı sağladı ve geceleri yedekler.

Bir şeyler ters giderse ve geri yüklemeniz gerekiyorsa, veritabanları gün boyunca kullanılırken dış diskten bazı okumalar yapacağınız için daha yavaş bir iyileşme olacağını tahmin ediyorum, ancak her şeyde her zaman ödünç var.

...

Her neyse, yapmaya çalıştığım nokta - her duruma uyan tek cevap yok. Eğer olsaydı, DBA'lar işsiz kalacaktı ve şirketler önceden oluşturulmuş veritabanı cihazları satın alacaktı.

Ele aldığım veritabanları patronumun 'WORN' olarak adlandırdığı şeydir: Bir Kez Yaz, Asla Oku; şaka yapıyor, ama "veri ambarı" herhangi bir faaliyet seviyesi anlamına gelebilir ... Gece / haftalık teypten yüklenen bazılarını gördüm (ve sadece OLTP örneğinin kopyalarıydı ve bantların iyi olduğunu doğrulamamıza yardımcı oldum) ve onlara büyük bir analiz işi yapıldı ve sürekli bir girdi ve arada sırada okuma akışı olan diğerleri vardı, ancak kaynaklar için gerçek bir rekabet yoktu.


1
Olumlu oyları olmadığı için Grr. Bu akţam buna geri geleceđim, çünkü puanlarýndan çok hoţlanýyorum. Ben de JBOD'un büyük bir hayranıyım, ya da tercihen birçok RAID1 çifti.
jcolebrand

@jcolebrand: aslında, bunu gönderdikten sonra Brian Ballsun-Stanton'un bahsettiği 'ASM'de okudum ve OS / FS / donanım düzeyinde Oracle işleme aynalama + şeritleme gibi görünüyor, bu yüzden benzer noktalar yaptık, ancak son Oracle yüklemeleri için daha iyi bir çözüm sundu.
Joe

Hangisi sizin önerdiğiniz gibi bir JBOD gerektirir, evet?
jcolebrand

@jcolebrand: hemen hemen. (tavsiye edilir, ancak gerekli olduğunu düşünmüyorum )
Joe

3

Sunucular için önerim her zaman RAID 5'dir . İlk başarısız sabit sürücünüzü kurtarmak için harcanan zaman ve çaba her zaman unutulmaz olacaktır. RAID dizileri ayarlarsanız, sunucu odasında tek bir sürücü boyutu ve yedek 2 yedek sabit sürücü üzerinde standartlaştırmanızı önemle tavsiye ederim. Bir sürücü kötü mü? Değiştirmelerden birini yerleştirin (ve dizinin yeniden oluşturulmasına izin verin). RAID dizilerinin sert düştüğünü gördüm, çünkü ilk gelmeyi beklerken ikinci bir sürücü kötüleşti (ertesi gün teslimat hala çok geçti).


Ama sabit diskleri değiştirmek DBA'nın alanı değil mi? Diskleri kullanım ömrü ve arıza oranı için izleme, SF kalabalığının otomatikleştirilmiş araçları içindir. İşi çoğaltmayalım ve uzmanlaşma nedenlerini yok edelim. Biz vardır ); dba en sonuçta
jcolebrand

Raid 5 nerede uygulandı? Donanım? Yazılım? Oracle? Kaç diskte? Oracle tarafından önerilen sürücü dizisi ne olacak? Arşiv günlüklerini yeniden yapmak bu değil mi?
Brian Ballsun-Stanton

2
RAID5'in önemli yazma performansı sorunları olabilir. RAID10, DB sunucuları için daha yaygındır.
David Spillett

@jcolebrand, Ağ yöneticileri için çalıştığım birçok şirket == sunucu yöneticileri == veritabanı yöneticileri. Bazılarında, üretim veri merkezine erişimi olan sadece birkaç kişi var, bu yüzden aynı anda 2 şapka takmak zorundalar. Çalıştığım birçok kişide, sunucu yöneticileri neler olup bittiğini bilmiyor, bu yüzden dahil oluyorum, bu yüzden işlerini de bilmeliyim.
Tangurena

Bu harika ve aynı zamanda berbat. Deneyimin sesini
duyduğuma

2

Ne kadar veri kullanmayı planlıyorsunuz ve sistemden ne kadar sıklıkla okuma-yazma yapacaksınız? Bunun içine giren çok fazla planlama var, bu yüzden bazı insanlar tüm akademik kariyeri konuya ayırıyor.

Normalde, birkaç RAID türü olduğundan ve her biri en iyi farklı bir yerde kullanıldığından, devam etmeden önce Wikipedia'ya gitmenizi ve makaleyi okumanızı söylerim.

Temel bilgiler şu şekildedir:

RAID0

Video oyuncuları için iyi. Hemen hemen herkes için kötü. Verileri herhangi bir süre tutması gerekmeyen bir önbellek sunucusu için bunu kullanmak kötü olmaz. Bir disk bozulduğunda sistem kapanır. Oyun bitti.

raıd1

Güvenilirlik için harika. Fazla genişleyemez. Hız oldukça iyi.

RAID5

RAID0 ve RAID1 (tür) arasında tercih edilen karışım.

Şimdi, bundan sonra, sunucu tasarımı veritabanı tasarımından daha moreso olduğu için gerçekten ServerFault'da sorulması gereken bir şey haline geliyor. Sunucu performansını her zaman Sunucu Yöneticinizle tartışın. Bunun için oradalar. Bu özel bir beta olmasaydı, sizi oraya taşımak için oy vermek isterdim.


2
ServerFault kesinlikle bu soru için yanlış bir yer olmasa da, muhtemelen doğru. G / Ç performans sorunları, DBA'nın iyi bilmesi gereken bir şeydir.
David Spillett

@David Kesinlikle katılıyorum, ancak beig farkında ve kendiniz belirtmekte bir fark var. Deneyimlerime göre, site büyük ve meşgul olacaktı hiç bir zaman tek bir görev değildi. İki kafa bir ve daha iyi
jcolebrand
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.