Əhəmiyyətli sayda Müəssisə proqramları və virtuallaşdırma sistemləri xətaya dözümlü həllər yaratmaq üçün öz mexanizmlərinə malikdir. Konkret olaraq, Oracle RAC (Oracle Real Application Cluster) yükü tarazlaşdırmaq və server/tətbiq səviyyəsində nasazlığa dözümlülüyü təmin etmək üçün birlikdə işləyən iki və ya daha çox Oracle verilənlər bazası serverindən ibarət klasterdir. Bu rejimdə işləmək üçün sizə adətən yaddaş sistemi olan ortaq yaddaş lazımdır.
Artıq birində müzakirə etdiyimiz kimi , saxlama sisteminin özü, təkrarlanan komponentlərin (o cümlədən nəzarətçilər) olmasına baxmayaraq, hələ də uğursuzluq nöqtələrinə malikdir - əsasən bir məlumat dəsti şəklində. Buna görə də, artan etibarlılıq tələbləri ilə Oracle həllini qurmaq üçün "N server - bir saxlama sistemi" sxemini mürəkkəbləşdirmək lazımdır.
İlk növbədə, əlbəttə ki, hansı risklərdən sığortalanmağa çalışdığımıza qərar verməliyik. Bu yazıda “meteorit gəldi” kimi təhlükələrdən qorunmağı nəzərdən keçirməyəcəyik. Beləliklə, coğrafi cəhətdən səpələnmiş fəlakətin bərpası həllinin qurulması növbəti məqalələrdən biri üçün mövzu olaraq qalacaq. Burada müdafiə server şkafları səviyyəsində qurulduqda, Cross-Rack fəlakətin bərpası həllinə baxacağıq. Şkafların özləri eyni otaqda və ya fərqli otaqlarda yerləşə bilər, lakin adətən eyni binanın içərisindədir.
Bu kabinetlərdə “qonşu”nun vəziyyətindən asılı olmayaraq Oracle verilənlər bazalarının işləməsinə imkan verəcək bütün zəruri avadanlıq və proqram təminatı olmalıdır. Başqa sözlə, Cross-Rack fəlakət bərpa həllindən istifadə edərək, uğursuzluq risklərini aradan qaldırırıq:
- Oracle Tətbiq Serverləri
- Saxlama sistemləri
- Kommutasiya sistemləri
- Şkafdakı bütün avadanlıqların tam sıradan çıxması:
- Gücdən imtina
- Soyutma sisteminin nasazlığı
- Xarici amillər (insan, təbiət və s.)
Oracle serverlərinin təkrarlanması Oracle RAC-ın iş prinsipini nəzərdə tutur və proqram vasitəsilə həyata keçirilir. Kommutasiya vasitələrinin təkrarlanması da problem deyil. Ancaq saxlama sisteminin təkrarlanması ilə hər şey o qədər də sadə deyil.
Ən sadə seçim məlumatların əsas saxlama sistemindən ehtiyat sistemə təkrarlanmasıdır. Saxlama sisteminin imkanlarından asılı olaraq sinxron və ya asinxron. Asinxron replikasiya ilə Oracle ilə əlaqəli məlumatların ardıcıllığını təmin etmək sualı dərhal ortaya çıxır. Tətbiqlə proqram inteqrasiyası olsa belə, hər halda, əsas yaddaş sistemində nasazlıq baş verərsə, klasteri ehtiyat yaddaşa keçirmək üçün idarəçilərin əl ilə müdaxiləsi tələb olunacaq.
Daha mürəkkəb seçim proqram və/yaxud aparat saxlama “virtualizatorları”dır ki, bu da ardıcıllıq problemlərini və əl ilə müdaxiləni aradan qaldıracaq. Lakin yerləşdirmə və sonrakı idarəetmənin mürəkkəbliyi, eləcə də bu cür həllərin çox nalayiq qiyməti çoxlarını qorxudur.
AccelStor NeoSapphire™ All Flash massiv həlli Cross-Rack fəlakətin bərpası kimi ssenarilər üçün mükəmməldir. Shared-Nothing arxitekturasından istifadə etməklə. Bu model fleş disklərlə işləmək üçün xüsusi FlexiRemap® texnologiyasından istifadə edən iki qovşaqlı yaddaş sistemidir. sayəsində NeoSapphire™ H710 600K IOPS@4K təsadüfi yazma və 1M+ IOPS@4K təsadüfi oxuma qabiliyyətinə malikdir, bu da klassik RAID əsaslı saxlama sistemlərindən istifadə edərkən əlçatmazdır.
Lakin NeoSapphire™ H710-un əsas xüsusiyyəti, hər birinin məlumatların öz nüsxəsinə malik olan ayrı-ayrı hallarda şəklində iki qovşaqın icrasıdır. Qovşaqlar InfiniBand xarici interfeysi vasitəsilə sinxronlaşdırılır. Bu arxitektura sayəsində qovşaqları 100 m-ə qədər məsafədə müxtəlif yerlərə paylamaq mümkündür və bununla da Cross-Rack fəlakətin bərpası həllini təmin edir. Hər iki qovşaq tamamilə sinxron işləyir. Ev sahibi tərəfdən H710 adi ikili nəzarətçi saxlama sisteminə bənzəyir. Buna görə də, hər hansı əlavə proqram və ya aparat seçimlərini və ya xüsusilə mürəkkəb parametrləri yerinə yetirməyə ehtiyac yoxdur.
Yuxarıda təsvir edilən bütün Cross-Rack fəlakət bərpa həllərini müqayisə etsək, AccelStor-dan olan seçim qalanlardan nəzərəçarpacaq dərəcədə fərqlənir:
AccelStor NeoSapphire™ heç bir şey arxitekturasını paylaşmadı
Proqram təminatı və ya aparat "virtualizator" saxlama sistemi
Replikasiyaya əsaslanan həll
Mövcudluq
Server nasazlığı
Boş vaxt yoxdur
Boş vaxt yoxdur
Boş vaxt yoxdur
Keçid uğursuzluğu
Boş vaxt yoxdur
Boş vaxt yoxdur
Boş vaxt yoxdur
Saxlama sistemində nasazlıq
Boş vaxt yoxdur
Boş vaxt yoxdur
Aşağı vaxt
Kabinetin tam uğursuzluğu
Boş vaxt yoxdur
Boş vaxt yoxdur
Aşağı vaxt
Xərc və mürəkkəblik
Həll dəyəri
Aşağı*
Yüksək
Yüksək
Yerləşdirmə mürəkkəbliyi
Aşağı
Yüksək
Yüksək
*AccelStor NeoSapphire™ hələ də All Flash massividir, onun tərifinə görə “3 qəpiyə” başa gəlmir, xüsusən də ikiqat tutum ehtiyatına malik olduğundan. Bununla belə, ona əsaslanan həllin son dəyərini digər satıcıların oxşarları ilə müqayisə edərkən, dəyəri aşağı hesab etmək olar.
Tətbiq serverlərini və Bütün Flash massiv qovşaqlarını birləşdirmək üçün topologiya belə görünəcək:
Topologiyanı planlaşdırarkən, idarəetmə açarlarının dublikatını və serverləri bir-birinə bağlamaq da tövsiyə olunur.
Burada və daha sonra Fiber Kanal vasitəsilə əlaqə haqqında danışacağıq. iSCSI istifadə etsəniz, hər şey eyni olacaq, istifadə olunan açar növlərinə və bir qədər fərqli massiv parametrlərinə uyğunlaşdırılacaq.
Massiv üzrə hazırlıq işləri
İstifadə olunan avadanlıq və proqram təminatı
Server və Switch Spesifikasiyaları
Components
Təsvir
Oracle Database 11g serverləri
Iki
Server əməliyyat sistemi
Oracle Linux
Oracle verilənlər bazası versiyası
11 q (RAC)
Hər serverə görə prosessorlar
İki 16 nüvəli Intel® Xeon® CPU E5-2667 v2 @ 3.30GHz
Hər server üçün fiziki yaddaş
128GB
FC şəbəkəsi
Çox yollu 16Gb/s FC
FC HBA
Emulex Lpe-16002B
Klasterin idarə edilməsi üçün xüsusi ictimai 1GbE portları
Intel ethernet adapteri RJ45
16Gb/s FC açarı
Brokar 6505
Məlumatların sinxronizasiyası üçün xüsusi 10GbE portlar
Intel X520
AccelStor NeoSapphire™ Bütün Flash Array Spesifikasiyası
Components
Təsvir
Saxlama sistemi
NeoSapphire™ yüksək əlçatanlıq modeli: H710
Şəkil versiyası
4.0.1
Sürücülərin ümumi sayı
48
Sürücü ölçüsü
1.92TB
Sürücü tipi
SSD
FC hədəf portları
16x 16Gb port (hər qovşaq üçün 8)
İdarəetmə limanları
Ethernet keçidi vasitəsilə hostlara qoşulan 1GbE ethernet kabeli
Ürək döyüntüsü portu
İki saxlama qovşağı arasında birləşdirən 1GbE ethernet kabeli
Məlumat sinxronizasiya portu
56Gb/s InfiniBand kabeli
Massivdən istifadə etməzdən əvvəl onu işə salmalısınız. Varsayılan olaraq, hər iki qovşağın idarəetmə ünvanı eynidir (192.168.1.1). Siz onlara bir-bir qoşulmalı və yeni (artıq fərqli) idarəetmə ünvanları təyin etməli və vaxt sinxronizasiyasını qurmalısınız, bundan sonra İdarəetmə portları bir şəbəkəyə qoşula bilər. Daha sonra qovşaqlar İnterlink bağlantıları üçün alt şəbəkələr təyin etməklə HA cütlüyünə birləşdirilir.
İnsializasiya başa çatdıqdan sonra siz istənilən qovşaqdan massivi idarə edə bilərsiniz.
Sonra, lazımi həcmləri yaradırıq və onları proqram serverlərində dərc edirik.
Oracle ASM üçün çoxsaylı cildlər yaratmaq tövsiyə olunur, çünki bu, serverlər üçün hədəflərin sayını artıracaq və nəticədə ümumi performansı yaxşılaşdıracaq (digərində növbələr haqqında daha çox məlumat). ).
Test konfiqurasiyası
Yaddaş Həcminin Adı
Həcm ölçüsü
Məlumat01
200GB
Məlumat02
200GB
Məlumat03
200GB
Məlumat04
200GB
Məlumat05
200GB
Məlumat06
200GB
Məlumat07
200GB
Məlumat08
200GB
Məlumat09
200GB
Məlumat10
200GB
Grid01
1GB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Grid05
1GB
Grid06
1GB
Yenidən 01
100GB
Yenidən 02
100GB
Yenidən 03
100GB
Yenidən 04
100GB
Yenidən 05
100GB
Yenidən 06
100GB
Yenidən 07
100GB
Yenidən 08
100GB
Yenidən 09
100GB
Yenidən 10
100GB
Massivin iş rejimləri və fövqəladə hallarda baş verən proseslər haqqında bəzi izahatlar
Hər bir qovşağın məlumat dəstində "versiya nömrəsi" parametri var. İlkin işə salındıqdan sonra eynidır və 1-ə bərabərdir. Nədənsə versiya nömrəsi fərqlidirsə, məlumatlar həmişə köhnə versiyadan daha gəncə sinxronlaşdırılır, bundan sonra gənc versiyanın sayı uyğunlaşdırılır, yəni. bu o deməkdir ki, nüsxələr eynidir. Versiyaların fərqli olmasının səbəbləri:
- Düyünlərdən birinin planlaşdırılmış yenidən işə salınması
- Birdən bağlanma (elektrik təchizatı, qızdırma və s.) səbəbindən qovşaqlardan birində qəza.
- Sinxronizasiya etmək mümkün olmadığı üçün InfiniBand bağlantısı itdi
- Məlumatların pozulması səbəbindən qovşaqlardan birində qəza. Burada yeni HA qrupu yaratmalı və məlumat dəstinin tam sinxronizasiyasını etməlisiniz.
Hər halda, onlayn qalan qovşaq cütlüklə əlaqə bərpa edildikdən sonra məlumat dəstini sinxronlaşdırmaq üçün versiya nömrəsini bir artırır.
Ethernet bağlantısı üzərindən əlaqə kəsilərsə, Heartbeat müvəqqəti olaraq InfiniBand-a keçir və bərpa edildikdən sonra 10 saniyə ərzində geri qayıdır.
Hostların qurulması
Arızaya dözümlülüyü təmin etmək və performansı artırmaq üçün siz massiv üçün MPIO dəstəyini aktivləşdirməlisiniz. Bunu etmək üçün, /etc/multipath.conf faylına sətirlər əlavə etməli və sonra çox yollu xidmətini yenidən başladın.
Gizli mətncihazlar {
qurğu {
satıcı "AStor"
path_grouping_policy "group_by_prio"
path_selector "növbə uzunluğu 0"
path_checker "tur"
xüsusiyyətləri "0"
hardware_handler "0"
əvvəl "const"
dərhal uğursuzluq
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names bəli
aşkar_prio bəli
rr_min_io_rq 1
no_path_retry 0
}
}
Sonra, ASM-nin ASMLib vasitəsilə MPIO ilə işləməsi üçün siz /etc/sysconfig/oracleasm faylını dəyişdirməli və sonra /etc/init.d/oracleasm skanerlərini işə salmalısınız.
Gizli mətn
# ORACLEASM_SCANORDER: Disk skanını sifariş etmək üçün uyğun nümunələr
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Diskləri skandan çıxarmaq üçün uyğun nümunələr
ORACLEASM_SCANEXCLUDE="sd"
Qeyd
ASMLib-dən istifadə etmək istəmirsinizsə, ASMLib üçün əsas olan UDEV qaydalarından istifadə edə bilərsiniz.
Oracle Database-nin 12.1.0.2 versiyasından başlayaraq, seçim ASMFD proqramının bir hissəsi kimi quraşdırma üçün əlçatandır.
Oracle ASM üçün yaradılmış disklərin massivin fiziki olaraq işlədiyi blok ölçüsünə uyğun olmasını təmin etmək vacibdir (4K). Əks halda, performans problemləri yarana bilər. Buna görə müvafiq parametrləri olan həcmlər yaratmaq lazımdır:
parted /dev/mapper/cihaz adı mklabel gpt mkpart ibtidai 2048s 100% align-yoxla optimal 1
Test konfiqurasiyamız üçün verilənlər bazalarının yaradılmış həcmlər üzrə paylanması
Yaddaş Həcminin Adı
Həcm ölçüsü
Həcmi LUN-ların xəritələşdirilməsi
ASM Həcmi Cihaz Təfərrüatı
Bölmə Vahidinin Ölçüsü
Məlumat01
200GB
Bütün saxlama həcmlərini yaddaş sisteminə bütün məlumat portlarına uyğunlaşdırın
Artıqlıq: Normal
Adı: DGDATA
Məqsəd: Məlumat faylları
4MB
Məlumat02
200GB
Məlumat03
200GB
Məlumat04
200GB
Məlumat05
200GB
Məlumat06
200GB
Məlumat07
200GB
Məlumat08
200GB
Məlumat09
200GB
Məlumat10
200GB
Grid01
1GB
Artıqlıq: Normal
Adı: DGGRID1
Məqsəd: Şəbəkə: CRS və Səsvermə
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Artıqlıq: Normal
Adı: DGGRID2
Məqsəd: Şəbəkə: CRS və Səsvermə
4MB
Grid05
1GB
Grid06
1GB
Yenidən 01
100GB
Artıqlıq: Normal
Adı: DGREDO1
Məqsəd: Mövzu 1-in qeydini təkrarlayın
4MB
Yenidən 02
100GB
Yenidən 03
100GB
Yenidən 04
100GB
Yenidən 05
100GB
Yenidən 06
100GB
Artıqlıq: Normal
Adı: DGREDO2
Məqsəd: Mövzu 2-in qeydini təkrarlayın
4MB
Yenidən 07
100GB
Yenidən 08
100GB
Yenidən 09
100GB
Yenidən 10
100GB
Verilənlər Bazasının Parametrləri
- Blok ölçüsü = 8K
- Swap sahəsi = 16 GB
- AMM (Avtomatik Yaddaş İdarəetmə) deaktiv edin
- Şəffaf Böyük Səhifələri deaktiv edin
Digər parametrlər
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmal 31457280
✓ kernel.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 istifadə edirsinizsə bunu təyin etməyin
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ yumşaq nproc 2047 şəbəkəsi
✓ şəbəkə sərt nproc 16384
✓ grid soft nofile 1024
✓ grid hard nofile 65536
✓ şəbəkə yumşaq yığını 10240
✓ grid hard stack 32768
✓ oracle soft nproc 2047
✓ oracle hard nproc 16384
✓ oracle soft nofile 1024
✓ oracle hard nofile 65536
✓ oracle soft stack 10240
✓ oracle hard stack 32768
✓ yumşaq memlock 120795954
✓ sərt memlock 120795954
sqlplus "/ sysdba olaraq"
sistem dəsti proseslərini dəyişdirin = 2000 əhatə dairəsi = spfile;
sistem dəstini dəyişdir open_cursors=2000 əhatə dairəsi=spfile;
sistem dəstini dəyişdir session_cached_cursors=300 əhatə dairəsi=spfile;
sistem dəstini dəyişdirin db_files=8192 əhatə dairəsi=spfile;
Uğursuzluq testi
Nümayiş məqsədləri üçün HammerDB OLTP yükünü təqlid etmək üçün istifadə edilmişdir. HammerDB konfiqurasiyası:
Anbarların sayı
256
İstifadəçi başına cəmi əməliyyatlar
1000000000000
Virtual İstifadəçilər
256
Nəticə 2.1M TPM oldu ki, bu da serialın performans limitindən çox uzaqdır , lakin serverlərin cari aparat konfiqurasiyası (ilk növbədə prosessorlara görə) və onların sayı üçün “tavan”dır. Bu testin məqsədi hələ də maksimum performansa nail olmaq deyil, bütövlükdə həllin nasazlıqlara dözümlülüyünü nümayiş etdirməkdir. Ona görə də biz sadəcə olaraq bu rəqəm üzərində quracağıq.
Düyünlərdən birinin uğursuzluğunu yoxlayın
Ev sahibləri anbara gedən yolların bir hissəsini itirdilər, qalanları ikinci node ilə işləməyə davam etdilər. Yenidən qurulan yollar səbəbindən performans bir neçə saniyə azaldı və sonra normal vəziyyətə düşdü. Xidmətdə heç bir fasilə olmayıb.
Bütün avadanlıqla şkafın nasazlıq testi
Bu halda, performans da yolların yenidən qurulması səbəbindən bir neçə saniyə azaldı və sonra orijinal dəyərin yarısına qayıtdı. Bir proqram serverinin fəaliyyətdən kənarlaşdırılması səbəbindən nəticə ilkin göstəricidən iki dəfə azaldı. Xidmətdə də heç bir fasilə olmayıb.
Oracle üçün münasib qiymətə və az yerləşdirmə/idarəetmə səyləri ilə nasazlığa dözümlü Cross-Rack fəlakət bərpa həllinin tətbiqinə ehtiyac varsa, Oracle RAC və memarlıq birlikdə işləyir. ən yaxşı variantlardan biri olacaq. Oracle RAC əvəzinə, məsələn, klasterləşdirməni, eyni DBMS və ya virtuallaşdırma sistemlərini təmin edən hər hansı digər proqram ola bilər. Həllin qurulması prinsipi eyni qalacaq. Və alt xətt RTO və RPO üçün sıfırdır.
Mənbə: www.habr.com