Huomattavalla osalla Enterprise-sovelluksia ja virtualisointijärjestelmiä on omat mekanisminsa vikasietoisten ratkaisujen rakentamiseen. Tarkemmin sanottuna Oracle RAC (Oracle Real Application Cluster) on kahden tai useamman Oracle-tietokantapalvelimen klusteri, jotka toimivat yhdessä tasapainottaakseen kuormitusta ja tarjotakseen vikasietoisuutta palvelin/sovellustasolla. Tässä tilassa työskentelyyn tarvitaan jaettu tallennustila, joka on yleensä tallennusjärjestelmä.
Kuten olemme jo keskustelleet yhdessä meidän , itse tallennusjärjestelmässä on päällekkäisistä komponenteista huolimatta (mukaan lukien ohjaimet) edelleen vikakohtia - pääasiassa yhden tietojoukon muodossa. Siksi "N palvelinta - yksi tallennusjärjestelmä" -mallin on oltava monimutkainen, jotta voidaan rakentaa Oracle-ratkaisu, jolla on korkeammat luotettavuusvaatimukset.
Ensin meidän on tietysti päätettävä, mitä riskejä vastaan yritämme vakuuttaa. Tässä artikkelissa emme harkitse suojaa sellaisilta uhilta kuin "meteoriitti on saapunut". Joten maantieteellisesti hajallaan olevan katastrofipalautusratkaisun rakentaminen jää aiheeksi johonkin seuraavista artikkeleista. Tässä tarkastellaan ns. Cross-Rack-katastrofipalautusratkaisua, kun suojaus rakennetaan palvelinkaappien tasolle. Itse kaapit voivat sijaita samassa huoneessa tai eri tiloissa, mutta yleensä samassa rakennuksessa.
Näiden kaappien tulee sisältää kaikki tarvittavat laitteet ja ohjelmistot, jotka mahdollistavat Oraclen tietokantojen toiminnan "naapurin" tilasta riippumatta. Toisin sanoen käyttämällä Cross-Rack-katastrofipalautusratkaisua eliminoimme epäonnistumisriskit:
- Oracle-sovelluspalvelimet
- Varastointijärjestelmät
- Kytkentäjärjestelmät
- Kaikkien kaapin laitteiden täydellinen vika:
- Vallan kieltäytyminen
- Jäähdytysjärjestelmän vika
- Ulkoiset tekijät (ihminen, luonto jne.)
Oracle-palvelimien monistaminen edellyttää Oracle RAC:n toimintaperiaatetta, ja se toteutetaan sovelluksen kautta. Vaihtomahdollisuuksien päällekkäisyys ei myöskään ole ongelma. Mutta tallennusjärjestelmän päällekkäisyydellä kaikki ei ole niin yksinkertaista.
Yksinkertaisin vaihtoehto on tietojen replikointi päätallennusjärjestelmästä varmuuskopiojärjestelmään. Synkroninen tai asynkroninen tallennusjärjestelmän ominaisuuksien mukaan. Asynkronisessa replikaatiossa herää heti kysymys tietojen johdonmukaisuuden varmistamisesta Oraclen suhteen. Mutta vaikka ohjelmisto on integroitu sovelluksen kanssa, päätallennusjärjestelmän vian sattuessa järjestelmänvalvojat tarvitsevat manuaalisia toimia klusterin vaihtamiseksi varmuuskopiotallennustilaan.
Monimutkaisempi vaihtoehto ovat ohjelmisto- ja/tai laitteistotallennusvirtualisoijat, jotka poistavat johdonmukaisuusongelmat ja manuaaliset toimenpiteet. Mutta käyttöönoton ja myöhemmän hallinnon monimutkaisuus sekä tällaisten ratkaisujen erittäin kohtuuttomat kustannukset pelottavat monia.
AccelStor NeoSapphire™ All Flash array -ratkaisu sopii täydellisesti skenaarioihin, kuten Cross-Rack-katastrofipalautukseen käyttämällä Shared-Nothing-arkkitehtuuria. Tämä malli on kahden solmun tallennusjärjestelmä, joka käyttää patentoitua FlexiRemap®-tekniikkaa työskennelläkseen flash-asemien kanssa. Kiitokset NeoSapphire™ H710 pystyy tarjoamaan jopa 600 4 IOPS@1K satunnaisen kirjoituksen ja 4 M+ IOPS@XNUMXK satunnaislukumäärän, mikä ei ole saavutettavissa käytettäessä klassisia RAID-pohjaisia tallennusjärjestelmiä.
Mutta NeoSapphire™ H710:n pääominaisuus on kahden solmun suorittaminen erillisissä tapauksissa, joista jokaisella on oma kopio tiedoista. Solmujen synkronointi tapahtuu ulkoisen InfiniBand-liitännän kautta. Tämän arkkitehtuurin ansiosta on mahdollista jakaa solmut eri paikkoihin jopa 100 metrin etäisyydelle, mikä tarjoaa Cross-Rack-katastrofipalautusratkaisun. Molemmat solmut toimivat täysin synkronisesti. Isäntäpuolelta H710 näyttää tavalliselta kahden ohjaimen tallennusjärjestelmältä. Siksi ei tarvitse suorittaa mitään lisäohjelmisto- tai laitteistovaihtoehtoja tai erityisen monimutkaisia asetuksia.
Jos vertaamme kaikkia edellä kuvattuja Cross-Rackin katastrofipalautusratkaisuja, niin AccelStorin vaihtoehto erottuu huomattavasti muista:
AccelStor NeoSapphire™ Shared Nothing Architecture
Ohjelmiston tai laitteiston "virtualisointi" -tallennusjärjestelmä
Replikointiin perustuva ratkaisu
saatavuus
Palvelinvirhe
Ei seisokkeja
Ei seisokkeja
Ei seisokkeja
Kytkimen vika
Ei seisokkeja
Ei seisokkeja
Ei seisokkeja
Tallennusjärjestelmän vika
Ei seisokkeja
Ei seisokkeja
Seisokkeja
Koko kaappivika
Ei seisokkeja
Ei seisokkeja
Seisokkeja
Kustannukset ja monimutkaisuus
Ratkaisun hinta
Matala*
Korkea
Korkea
Käyttöönoton monimutkaisuus
alhainen
Korkea
Korkea
*AccelStor NeoSapphire™ on edelleen All Flash -taulukko, joka ei määritelmän mukaan maksa "3 kopekkaa", varsinkin kun siinä on kaksinkertainen kapasiteettireservi. Kuitenkin, kun verrataan siihen perustuvan ratkaisun lopullista hintaa muiden valmistajien vastaaviin ratkaisuihin, kustannuksia voidaan pitää alhaisena.
Sovelluspalvelimien ja kaikkien Flash-ryhmän solmujen yhdistämisen topologia näyttää tältä:
Topologiaa suunniteltaessa on myös erittäin suositeltavaa monistaa hallintakytkimiä ja yhdistää palvelimia.
Täällä ja edelleen puhumme yhteyden muodostamisesta kuitukanavan kautta. Jos käytät iSCSI:tä, kaikki on sama, mukautettu käytettyjen kytkimien tyyppeihin ja hieman erilaisiin matriisiin.
Taulukon valmistelutyöt
Käytetyt laitteet ja ohjelmistot
Palvelimen ja kytkimen tekniset tiedot
Компоненты
Kuvaus
Oracle Database 11g -palvelimet
kaksi
Palvelimen käyttöjärjestelmä
Oracle Linux
Oracle-tietokannan versio
11g (RAC)
Prosessorit per palvelin
Kaksi 16 ydintä Intel® Xeon® CPU E5-2667 v2 @ 3.30 GHz
Fyysinen muisti per palvelin
128GB
FC verkko
16 Gb/s FC monitieyhteydellä
FC HBA
Emulex Lpe-16002B
Julkiset 1GbE-portit klusterin hallintaan
Intel ethernet-sovitin RJ45
16Gb/s FC-kytkin
Brocade 6505
Yksityiset 10 GbE-portit tietojen synkronointia varten
Intel X520
AccelStor NeoSapphire™ All Flash Array -määritykset
Компоненты
Kuvaus
Varastointijärjestelmä
NeoSapphire™ korkean käytettävyyden malli: H710
Kuvan versio
4.0.1
Asemien kokonaismäärä
48
Aseman koko
1.92TB
Ajotyyppi
SSD
FC kohdeportit
16 x 16 Gb portit (8 solmua kohti)
Hallintaportit
1GbE-ethernet-kaapeli, joka liitetään isäntiin ethernet-kytkimen kautta
Sydämenlyöntiportti
1 GbE:n Ethernet-kaapeli, joka yhdistää kahden tallennussolmun välille
Tietojen synkronointiportti
56Gb/s InfiniBand-kaapeli
Ennen kuin voit käyttää taulukkoa, sinun on alustettava se. Oletuksena molempien solmujen ohjausosoite on sama (192.168.1.1). Niihin täytyy muodostaa yhteys yksitellen ja asettaa uudet (jo erilaiset) hallintaosoitteet ja aikasynkronointi, jonka jälkeen Management-portit voidaan liittää yhteen verkkoon. Myöhemmin solmut yhdistetään HA-pariksi määrittämällä aliverkot Interlink-yhteyksille.
Kun alustus on valmis, voit hallita taulukkoa mistä tahansa solmusta.
Seuraavaksi luomme tarvittavat taltiot ja julkaisemme ne sovelluspalvelimille.
On erittäin suositeltavaa luoda useita levyjä Oracle ASM:lle, koska tämä lisää palvelimien kohteiden määrää, mikä lopulta parantaa yleistä suorituskykyä (lisää jonoista toisessa ).
Testaa konfiguraatiota
Tallennustilan nimi
Tilavuuden koko
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
Tee uudelleen01
100GB
Tee uudelleen02
100GB
Tee uudelleen03
100GB
Tee uudelleen04
100GB
Tee uudelleen05
100GB
Tee uudelleen06
100GB
Tee uudelleen07
100GB
Tee uudelleen08
100GB
Tee uudelleen09
100GB
Tee uudelleen10
100GB
Muutama selostus taulukon toimintatavoista ja hätätilanteissa tapahtuvista prosesseista
Jokaisen solmun tietojoukossa on "versionumero"-parametri. Alkualustuksen jälkeen se on sama ja yhtä suuri kuin 1. Jos jostain syystä versionumero on eri, niin tiedot synkronoidaan aina vanhemmasta versiosta nuorempaan, minkä jälkeen nuoremman version numero tasataan, ts. tämä tarkoittaa, että kopiot ovat identtisiä. Syitä siihen, miksi versiot voivat olla erilaisia:
- Yhden solmun ajoitettu uudelleenkäynnistys
- Onnettomuus yhdessä solmussa äkillisen sammutuksen vuoksi (virtalähde, ylikuumeneminen jne.).
- InfiniBand-yhteys katkesi, koska synkronointi ei onnistu
- Kaatuminen yhdessä solmuista tietojen vioittumisen vuoksi. Täällä sinun on luotava uusi HA-ryhmä ja suoritettava tietojoukon synkronointi.
Joka tapauksessa online-tilassa oleva solmu kasvattaa versionumeroaan yhdellä synkronoidakseen tietojoukonsa, kun yhteys pariin on palautettu.
Jos yhteys Ethernet-linkin kautta katkeaa, Heartbeat vaihtaa tilapäisesti InfiniBandiin ja palaa takaisin 10 sekunnin kuluessa, kun se palautetaan.
Isäntien asettaminen
Vikasietoisuuden varmistamiseksi ja suorituskyvyn parantamiseksi sinun on otettava käyttöön MPIO-tuki ryhmälle. Tätä varten sinun on lisättävä rivejä /etc/multipath.conf-tiedostoon ja käynnistettävä sitten monitiepalvelu uudelleen.
Piilotettu tekstilaitteet {
laite {
myyjä "AStor"
path_grouping_policy "group_by_prio"
polun_valitsin "jonon pituus 0"
polun_tarkistus "tur"
ominaisuuksia "0"
hardware_handler "0"
ennen "const"
välitön epäonnistuminen
fast_io_fail_tmo 5
dev_loss_tmo 60
käyttäjäystävälliset_nimet kyllä
detect_prio kyllä
rr_min_io_rq 1
no_path_retry 0
}
}
Seuraavaksi, jotta ASM voisi toimia MPIO:n kanssa ASMLibin kautta, sinun on muutettava /etc/sysconfig/oracleasm-tiedosto ja suoritettava sitten /etc/init.d/oracleasm scandisks
Piilotettu teksti
# ORACLEASM_SCANORDER: Kuvioiden sovittaminen levyn skannauksen järjestykseen
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Vastaavat kuviot levyjen poissulkemiseksi tarkistuksesta
ORACLEASM_SCANEXCLUDE="sd"
Huomata
Jos et halua käyttää ASMLibia, voit käyttää UDEV-sääntöjä, jotka ovat ASMLibin perusta.
Oracle Databasen versiosta 12.1.0.2 alkaen vaihtoehto on saatavana asennettavaksi osana ASMFD-ohjelmistoa.
On välttämätöntä varmistaa, että Oracle ASM:lle luodut levyt on kohdistettu sen lohkokoon kanssa, jonka kanssa ryhmä fyysisesti toimii (4K). Muuten voi ilmetä suorituskykyongelmia. Siksi on tarpeen luoda volyymit sopivilla parametreilla:
parted /dev/mapper/device-name mklabel gpt mkpart ensisijainen 2048s 100 % align-check optimaalinen 1
Tietokantojen jakautuminen luotujen taltioiden kesken testikokoonpanoamme varten
Tallennustilan nimi
Tilavuuden koko
Volume LUN -kartoitus
ASM Volume Device Detail
Jakoyksikön koko
Data01
200GB
Yhdistä kaikki tallennustilastot tallennusjärjestelmän kaikki tietoportit
Redundanssi: Normaali
Nimi: DGDATA
Tarkoitus: Datatiedostot
4MB
Data02
200GB
Data03
200GB
Data04
200GB
Data05
200GB
Data06
200GB
Data07
200GB
Data08
200GB
Data09
200GB
Data10
200GB
Grid01
1GB
Redundanssi: Normaali
Nimi: DGGRID1
Tarkoitus: Verkko: CRS ja äänestys
4MB
Grid02
1GB
Grid03
1GB
Grid04
1GB
Redundanssi: Normaali
Nimi: DGGRID2
Tarkoitus: Verkko: CRS ja äänestys
4MB
Grid05
1GB
Grid06
1GB
Tee uudelleen01
100GB
Redundanssi: Normaali
Nimi: DGREDO1
Tarkoitus: Tee uudelleen säikeen 1 loki
4MB
Tee uudelleen02
100GB
Tee uudelleen03
100GB
Tee uudelleen04
100GB
Tee uudelleen05
100GB
Tee uudelleen06
100GB
Redundanssi: Normaali
Nimi: DGREDO2
Tarkoitus: Tee uudelleen säikeen 2 loki
4MB
Tee uudelleen07
100GB
Tee uudelleen08
100GB
Tee uudelleen09
100GB
Tee uudelleen10
100GB
Tietokannan asetukset
- Lohkon koko = 8K
- Vaihtotila = 16 Gt
- Poista AMM (Automatic Memory Management) käytöstä
- Poista läpinäkyvät valtavat sivut käytöstä
Muut asetukset
# 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 # älä aseta tätä, jos käytät Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ grid soft nproc 2047
✓ Grid hard nproc 16384
✓ ruudukon pehmeä nofile 1024
✓ ruudukon kova nofile 65536
✓ ruudukon pehmeä pino 10240
✓ ruudukon kova pino 32768
✓ Oracle soft nproc 2047
✓ Oracle hard nproc 16384
✓ Oracle soft nofile 1024
✓ Oracle hard nofile 65536
✓ Oracle soft stack 10240
✓ Oracle hard pino 32768
✓ pehmeä memlock 120795954
✓ kova muistilukitus 120795954
sqlplus "/as sysdba"
muuta järjestelmäsarjan prosessit=2000 soveltamisala=spfile;
muuta järjestelmäjoukkoa open_cursors=2000 soveltamisala=spfile;
muuta järjestelmäjoukko session_cached_cursors=300 soveltamisala=spfile;
muuta järjestelmäjoukkoa db_files=8192 soveltamisala=spfile;
Epäonnistumisen testi
Esittelytarkoituksiin HammerDB:tä käytettiin emuloimaan OLTP-kuormaa. HammerDB-kokoonpano:
Varastojen lukumäärä
256
Tapahtumat yhteensä käyttäjää kohti
1000000000000
Virtuaaliset käyttäjät
256
Tuloksena oli 2.1 M TPM, mikä on kaukana taulukon suorituskyvyn rajasta , mutta se on "katto" palvelimien nykyiselle laitteistokokoonpanolle (johtuen ensisijaisesti prosessoreista) ja niiden lukumäärälle. Tämän testin tarkoituksena on edelleen osoittaa ratkaisun vikasietoisuus kokonaisuutena, eikä saavuttaa maksimaalista suorituskykyä. Siksi rakennamme vain tämän luvun pohjalta.
Testaa jonkin solmun vika
Isännät menettivät osan polkuista tallennustilaan ja jatkoivat jäljellä olevien läpivientiä toisen solmun kanssa. Suorituskyky heikkeni muutaman sekunnin, koska polkuja rakennettiin uudelleen, ja palasi sitten normaaliksi. Palvelussa ei ollut katkosta.
Kaapin vikatesti kaikilla laitteilla
Tässä tapauksessa suorituskyky laski myös muutaman sekunnin ajan polkujen uudelleenjärjestelyn vuoksi ja palasi sitten puoleen alkuperäisestä arvosta. Tulos puolittui alkuperäisestä, koska yksi sovelluspalvelin suljettiin pois toiminnasta. Palvelussa ei myöskään ollut katkosta.
Jos Oraclelle on tarpeen ottaa käyttöön vikasietoinen Cross-Rack-katastrofipalautusratkaisu kohtuullisin kustannuksin ja vähäisellä käyttöönotto-/hallintatyöllä, Oracle RAC ja arkkitehtuuri toimivat yhdessä. tulee olemaan yksi parhaista vaihtoehdoista. Oracle RAC:n sijaan voi olla mikä tahansa muu ohjelmisto, joka tarjoaa klusteroinnin, esimerkiksi samat DBMS- tai virtualisointijärjestelmät. Ratkaisun rakentamisperiaate pysyy samana. Ja lopputulos on nolla RTO:lle ja RPO:lle.
Lähde: will.com