Önemli sayıda Kurumsal uygulama ve sanallaştırma sistemi, hataya dayanıklı çözümler oluşturmak için kendi mekanizmalarına sahiptir. Özellikle Oracle RAC (Oracle Real Application Cluster), yükü dengelemek ve sunucu/uygulama düzeyinde hata toleransı sağlamak için birlikte çalışan iki veya daha fazla Oracle veritabanı sunucusundan oluşan bir kümedir. Bu modda çalışmak için genellikle bir depolama sistemi olan paylaşılan bir depolama alanına ihtiyacınız vardır.
Daha önce bir makalemizde tartıştığımız gibi , depolama sisteminin kendisi, yinelenen bileşenlerin (denetleyiciler dahil) varlığına rağmen, esas olarak tek bir veri kümesi biçiminde hala arıza noktalarına sahiptir. Bu nedenle, artan güvenilirlik gereksinimlerine sahip bir Oracle çözümü oluşturmak için "N sunucu - tek depolama sistemi" şemasının karmaşık olması gerekir.
Öncelikle elbette hangi risklere karşı sigorta yaptırmaya çalıştığımıza karar vermemiz gerekiyor. Bu yazımızda “göktaşı geldi” gibi tehditlere karşı korunmayı ele almayacağız. Dolayısıyla coğrafi olarak dağınık bir felaket kurtarma çözümü oluşturmak, aşağıdaki makalelerden birinin konusu olmaya devam edecek. Burada, koruma sunucu dolapları düzeyinde oluşturulduğunda Cross-Rack felaket kurtarma çözümüne bakacağız. Dolapların kendileri aynı odada veya farklı odalarda bulunabilir, ancak genellikle aynı bina içinde bulunabilir.
Bu dolaplar, “komşunun” durumuna bakılmaksızın Oracle veritabanlarının çalışmasına olanak sağlayacak gerekli tüm ekipman ve yazılım setini içermelidir. Başka bir deyişle Cross-Rack felaket kurtarma çözümünü kullanarak arıza risklerini ortadan kaldırıyoruz:
- Oracle Uygulama Sunucuları
- Depolama sistemleri
- Anahtarlama sistemleri
- Kabindeki tüm ekipmanların tamamen arızalanması:
- Güç reddi
- Soğutma sistemi arızası
- Dış faktörler (insan, doğa vb.)
Oracle sunucularının çoğaltılması, Oracle RAC'ın çalışma prensibini ifade eder ve bir uygulama aracılığıyla uygulanır. Anahtarlama tesislerinin çoğaltılması da sorun değildir. Ancak depolama sisteminin çoğaltılmasıyla her şey o kadar basit değil.
En basit seçenek, ana depolama sisteminden yedek sisteme veri kopyalamadır. Depolama sisteminin yeteneklerine bağlı olarak eşzamanlı veya eşzamansız. Eşzamansız çoğaltmayla, Oracle ile ilgili olarak veri tutarlılığının sağlanması sorusu hemen ortaya çıkar. Ancak uygulama ile yazılım entegrasyonu olsa bile her halükarda ana depolama sisteminde bir arıza olması durumunda, kümenin yedek depolamaya geçirilmesi için yöneticilerin manuel müdahalesi gerekecektir.
Daha karmaşık bir seçenek ise tutarlılık sorunlarını ve manuel müdahaleyi ortadan kaldıracak yazılım ve/veya donanım depolama "sanallaştırıcılarıdır". Ancak dağıtımın ve sonraki yönetimin karmaşıklığı ve bu tür çözümlerin çok uygunsuz maliyeti birçok kişiyi korkutuyor.
AccelStor NeoSapphire™ All Flash dizi çözümü, Cross-Rack felaket kurtarma gibi senaryolar için mükemmeldir Paylaşılan Hiçbir Şey mimarisini kullanma. Bu model, flash sürücülerle çalışmak için tescilli FlexiRemap® teknolojisini kullanan iki düğümlü bir depolama sistemidir. Sayesinde NeoSapphire™ H710, klasik RAID tabanlı depolama sistemleri kullanıldığında ulaşılamayan 600K IOPS@4K rastgele yazma ve 1M+ IOPS@4K rastgele okuma performansı sunma kapasitesine sahiptir.
Ancak NeoSapphire™ H710'un ana özelliği, her biri kendi veri kopyasına sahip olan iki düğümün ayrı vakalar biçiminde yürütülmesidir. Düğümlerin senkronizasyonu harici InfiniBand arayüzü aracılığıyla gerçekleştirilir. Bu mimari sayesinde düğümlerin 100m mesafeye kadar farklı lokasyonlara dağıtılması sağlanarak Cross-Rack felaket kurtarma çözümü sağlanmış olur. Her iki düğüm de tamamen senkronize olarak çalışır. Ana bilgisayar tarafından H710 sıradan bir çift denetleyicili depolama sistemine benziyor. Bu nedenle herhangi bir ek yazılım veya donanım seçeneği veya özellikle karmaşık ayarlar yapılmasına gerek yoktur.
Yukarıda açıklanan tüm Cross-Rack felaket kurtarma çözümlerini karşılaştırırsak, AccelStor seçeneği diğerlerinden belirgin şekilde öne çıkıyor:
AccelStor NeoSapphire™ Paylaşılan Hiçbir Şey Mimarisi
Yazılım veya donanım “sanallaştırıcı” depolama sistemi
Çoğaltma tabanlı çözüm
Durumu
Sunucu hatası
Kesinti Yok
Kesinti Yok
Kesinti Yok
Anahtar hatası
Kesinti Yok
Kesinti Yok
Kesinti Yok
Depolama sistemi hatası
Kesinti Yok
Kesinti Yok
Kesinti
Tüm kabin arızası
Kesinti Yok
Kesinti Yok
Kesinti
Maliyet ve karmaşıklık
Çözüm maliyeti
Düşük*
Yüksek
Yüksek
Dağıtım karmaşıklığı
düşük
Yüksek
Yüksek
*AccelStor NeoSapphire™ hala bir All Flash dizisidir ve özellikle iki kat kapasite rezervine sahip olduğundan tanımı gereği "3 kopek" maliyeti yoktur. Bununla birlikte, buna dayalı bir çözümün nihai maliyetini diğer satıcıların benzerleriyle karşılaştırırken maliyetin düşük olduğu düşünülebilir.
Uygulama sunucularını ve Tüm Flash dizi düğümlerini bağlamak için topoloji şu şekilde görünecektir:
Topolojiyi planlarken, yönetim anahtarlarının ve ara bağlantı sunucularının çoğaltılması da önemle tavsiye edilir.
Burada ve daha sonra Fiber Kanal üzerinden bağlanmaktan bahsedeceğiz. iSCSI kullanıyorsanız, kullanılan anahtar türlerine ve biraz farklı dizi ayarlarına göre ayarlanmış her şey aynı olacaktır.
Dizi üzerinde hazırlık çalışması
Kullanılan ekipman ve yazılım
Sunucu ve Anahtar Özellikleri
Bileşenleri
Açıklama
Oracle Veritabanı 11g sunucuları
Iki
Sunucu işletim sistemi
Oracle Linux
Oracle veritabanı sürümü
11g (RAC)
Sunucu başına işlemciler
İki adet 16 çekirdekli Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Sunucu başına fiziksel bellek
128GB
FC ağı
Çoklu yollu 16 Gb/s FC
FC HBA
Emulex Lpe-16002B
Küme yönetimi için özel genel 1GbE bağlantı noktaları
Intel ethernet adaptörü RJ45
16 Gb/sn FC anahtarı
Brokar 6505
Veri senkronizasyonu için özel 10GbE bağlantı noktaları
Intel X520
AccelStor NeoSapphire™ Tüm Flaş Dizisi Teknik Özellikleri
Bileşenleri
Açıklama
Depolama sistemi
NeoSapphire™ yüksek kullanılabilirlik modeli: H710
Resim sürümü
4.0.1
Toplam sürücü sayısı
48
Sürücü boyutu
1.92TB
Sürücü türü
SSD
FC hedef bağlantı noktaları
16x 16 Gb bağlantı noktası (düğüm başına 8)
Yönetim bağlantı noktaları
Bir Ethernet anahtarı aracılığıyla ana bilgisayarlara bağlanan 1GbE Ethernet kablosu
Kalp atışı bağlantı noktası
İki depolama düğümü arasında bağlanan 1GbE Ethernet kablosu
Veri senkronizasyon bağlantı noktası
56 Gb/sn InfiniBand kablosu
Bir diziyi kullanabilmeniz için önce onu başlatmanız gerekir. Varsayılan olarak her iki düğümün kontrol adresi aynıdır (192.168.1.1). Bunlara tek tek bağlanmanız, yeni (zaten farklı) yönetim adresleri ayarlamanız ve zaman senkronizasyonunu ayarlamanız gerekir; bunun ardından Yönetim bağlantı noktaları tek bir ağa bağlanabilir. Daha sonra düğümler, Interlink bağlantıları için alt ağlar atanarak bir HA çifti halinde birleştirilir.
Başlatma tamamlandıktan sonra diziyi herhangi bir düğümden yönetebilirsiniz.
Daha sonra gerekli birimleri oluşturup uygulama sunucularına yayınlıyoruz.
Oracle ASM için birden fazla birim oluşturulması önemle tavsiye edilir; çünkü bu, sunucular için hedef sayısını artıracak ve sonuçta genel performansı artıracaktır (kuyruklar hakkında daha fazla bilgi başka bir sayfada yer almaktadır). ).
Test yapılandırması
Depolama Birimi Adı
Hacim boyutu
Data01
200GB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Yinele01
100GB
Yinele02
100GB
Yinele03
100GB
Yinele04
100GB
Yinele05
100GB
Yinele06
100GB
Yinele07
100GB
Yinele08
100GB
Yinele09
100GB
Yinele10
100GB
Dizinin çalışma modları ve acil durumlarda meydana gelen süreçler hakkında bazı açıklamalar
Her düğümün veri setinde bir “versiyon numarası” parametresi bulunur. İlk başlatmadan sonra aynı olur ve 1'e eşittir. Herhangi bir nedenle sürüm numarası farklıysa, veriler her zaman eski sürümden yeni sürüme senkronize edilir, ardından daha genç sürümün numarası hizalanır, yani. bu, kopyaların aynı olduğu anlamına gelir. Sürümlerin farklı olmasının nedenleri:
- Düğümlerden birinin planlanmış yeniden başlatılması
- Ani kapanma (güç kaynağı, aşırı ısınma vb.) nedeniyle düğümlerden birinde meydana gelen kaza.
- Senkronize edilemeyen InfiniBand bağlantısı kesildi
- Veri bozulması nedeniyle düğümlerden birinde çökme. Burada yeni bir HA grubu oluşturmanız ve veri kümesinin senkronizasyonunu tamamlamanız gerekecektir.
Her durumda çevrimiçi kalan düğüm, çiftle bağlantı yeniden kurulduktan sonra veri setini senkronize etmek için sürüm numarasını birer birer artırır.
Ethernet bağlantısı üzerinden bağlantı kesilirse Heartbeat geçici olarak InfiniBand'a geçer ve geri yüklendiğinde 10 saniye içinde geri döner.
Ana bilgisayarları ayarlama
Hata toleransını sağlamak ve performansı artırmak için dizi için MPIO desteğini etkinleştirmeniz gerekir. Bunu yapmak için /etc/multipath.conf dosyasına satırlar eklemeniz ve ardından çoklu yol hizmetini yeniden başlatmanız gerekir.
Gizli metincihazlar {
cihaz {
satıcı "AStor"
path_grouping_policy "group_by_prio"
path_selector "sıra uzunluğu 0"
path_checker "tur"
"0" özellikleri
donanım_işleyicisi "0"
"const" önceliği
anında geri dönüş
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names evet
Detect_prio evet
rr_min_io_rq 1
no_path_yeniden dene 0
}
}
Daha sonra ASM'nin ASMLib aracılığıyla MPIO ile çalışabilmesi için /etc/sysconfig/oracleasm dosyasını değiştirmeniz ve ardından /etc/init.d/oracleasm scandisks komutunu çalıştırmanız gerekir.
Gizli metin
# ORACLEASM_SCANORDER: Disk taramasını sıralamak için eşleştirme desenleri
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Diskleri taramanın dışında bırakmak için eşleştirme kalıpları
ORACLEASM_SCANEXCLUDE="sd"
Dikkat
ASMLib'i kullanmak istemiyorsanız ASMLib'in temeli olan UDEV kurallarını kullanabilirsiniz.
Oracle Database'in 12.1.0.2 sürümünden itibaren bu seçenek, ASMFD yazılımının bir parçası olarak kurulum için mevcuttur.
Oracle ASM için oluşturulan disklerin, dizinin fiziksel olarak çalıştığı blok boyutuna (4K) uygun olduğundan emin olmak zorunludur. Aksi takdirde performans sorunları yaşanabilir. Bu nedenle uygun parametrelere sahip birimler oluşturmak gerekir:
bölümlenmiş /dev/mapper/cihaz-adı mklabel gpt mkpart birincil 2048s %100 hizalama kontrolü optimum 1
Test yapılandırmamız için veritabanlarının oluşturulan birimlere dağıtımı
Depolama Birimi Adı
Hacim boyutu
Birim LUN'larının eşlemesi
ASM Hacim Cihazı Detayı
Ayırma birimi boyutu
Data01
200GB
Tüm depolama birimlerini depolama sisteminin tüm veri bağlantı noktalarına eşleyin
Artıklık: Normal
İsim:DGDATA
Amaç:Veri dosyaları
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Artıklık: Normal
İsim: DGGRID1
Amaç: Izgara: CRS ve Oylama
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Artıklık: Normal
İsim: DGGRID2
Amaç: Izgara: CRS ve Oylama
4MB
Grid05
1GB
Grid06
1GB
Yinele01
100GB
Artıklık: Normal
İsim: DGREDO1
Amaç: 1. iş parçacığının günlüğünü yeniden yap
4MB
Yinele02
100GB
Yinele03
100GB
Yinele04
100GB
Yinele05
100GB
Yinele06
100GB
Artıklık: Normal
İsim: DGREDO2
Amaç: 2. iş parçacığının günlüğünü yeniden yap
4MB
Yinele07
100GB
Yinele08
100GB
Yinele09
100GB
Yinele10
100GB
Veritabanı Ayarları
- Blok boyutu = 8K
- Takas alanı = 16GB
- AMM'yi (Otomatik Bellek Yönetimi) Devre Dışı Bırak
- Şeffaf Büyük Sayfaları Devre Dışı Bırak
Diğer ayarlar
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 31457280
✓ çekirdek.shmmn 4096
✓ kernel.sem = 250 32000 100 128
✓ net.ipv4.ip_local_port_range = 9000 65500
✓ net.core.rmem_default = 262144
✓ net.core.rmem_max = 4194304
✓ net.core.wmem_default = 262144
✓ net.core.wmem_max = 1048586
✓vm.swappiness=10
✓ vm.min_free_kbytes=524288 # Linux x86 kullanıyorsanız bunu ayarlamayın
✓ vm.vfs_cache_press=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ ızgara yumuşak nproc 2047
✓ ızgara sert nproc 16384
✓ ızgara yumuşak dosya 1024
✓ ızgara sert nofile 65536
✓ ızgara yumuşak yığını 10240
✓ ızgara sabit yığını 32768
✓ oracle yumuşak nproc 2047
✓ Oracle sabit nproc 16384
✓ oracle soft nofile 1024
✓ Oracle sabit nofile 65536
✓ oracle yumuşak yığını 10240
✓ Oracle sabit yığını 32768
✓ yumuşak hafıza kilidi 120795954
✓ sabit memlock 120795954
sqlplus “/sysdba olarak”
sistem kümesi işlemlerini değiştir=2000 kapsam=spfile;
sistem setini değiştir open_cursors=2000 kapsam=spfile;
sistem setini değiştir session_cached_cursors=300 kapsam=spfile;
sistem setini değiştir db_files=8192 kapsam=spfile;
Arıza testi
Gösterim amacıyla, OLTP yükünü taklit etmek için HammerDB kullanıldı. HammerDB yapılandırması:
Depo Sayısı
256
Kullanıcı Başına Toplam İşlem
1000000000000
Sanal Kullanıcılar
256
Sonuç olarak 2.1 milyon TPM elde edildi; bu, dizinin performans sınırından çok uzaktır , ancak sunucuların mevcut donanım yapılandırması (öncelikle işlemciler nedeniyle) ve sayıları için bir "tavan" dır. Bu testin amacı yine de çözümün hata toleransını bir bütün olarak göstermektir, maksimum performansa ulaşmak değil. Bu nedenle, sadece bu rakamın üzerine inşa edeceğiz.
Düğümlerden birinin arızasını test edin
Ana bilgisayarlar, depolamaya giden yolların bir kısmını kaybetti ve geri kalanlar üzerinde ikinci düğümle çalışmaya devam etti. Yolların yeniden oluşturulması nedeniyle performans birkaç saniyeliğine düştü, ardından normale döndü. Hizmette herhangi bir aksama yaşanmadı.
Tüm ekipmanlarla kabin arıza testi
Bu durumda, yolların yeniden yapılandırılması nedeniyle performans da birkaç saniyeliğine düştü ve ardından orijinal değerin yarısına geri döndü. Bir uygulama sunucusunun çalışma dışı bırakılması nedeniyle sonuç ilk sonuca göre yarı yarıya azaldı. Hizmette de herhangi bir kesinti yaşanmadı.
Oracle için hataya dayanıklı bir Çapraz Raf felaket kurtarma çözümünü makul bir maliyetle ve çok az dağıtım/yönetim çabasıyla uygulamaya ihtiyaç varsa Oracle RAC ve mimarisi birlikte çalışır. en iyi seçeneklerden biri olacaktır. Oracle RAC yerine kümeleme sağlayan başka bir yazılım, örneğin aynı DBMS veya sanallaştırma sistemleri olabilir. Çözümü oluşturma ilkesi aynı kalacaktır. Ve sonuç olarak RTO ve RPO için sıfırdır.
Kaynak: habr.com