Un nombre considerable d'aplicacions empresarials i sistemes de virtualització tenen els seus propis mecanismes per crear solucions tolerants a errors. Concretament, Oracle RAC (Oracle Real Application Cluster) és un clúster de dos o més servidors de bases de dades Oracle que treballen junts per equilibrar la càrrega i proporcionar tolerància a errors a nivell de servidor/aplicació. Per treballar en aquest mode, necessiteu un emmagatzematge compartit, que normalment és un sistema d'emmagatzematge.
Com ja hem comentat en un dels nostres , el propi sistema d'emmagatzematge, malgrat la presència de components duplicats (inclosos controladors), encara té punts de fallada, principalment en forma d'un sol conjunt de dades. Per tant, per crear una solució Oracle amb més requisits de fiabilitat, l'esquema "N servidors: un sistema d'emmagatzematge" ha de ser complicat.
En primer lloc, per descomptat, hem de decidir contra quins riscos estem intentant assegurar-nos. En aquest article, no considerarem la protecció contra amenaces com "ha arribat un meteorit". Per tant, la creació d'una solució de recuperació de desastres dispersa geogràficament seguirà sent un tema per a un dels articles següents. Aquí veurem l'anomenada solució de recuperació de desastres Cross-Rack, quan la protecció es construeix a nivell dels armaris del servidor. Els propis armaris es poden situar a la mateixa habitació o en diferents, però normalment dins del mateix edifici.
Aquests gabinets han de contenir tot el conjunt necessari d'equips i programari que permetran el funcionament de les bases de dades Oracle independentment de l'estat del "veí". En altres paraules, amb la solució de recuperació de desastres Cross-Rack, eliminem els riscos de fallada:
- Servidors d'aplicacions Oracle
- Sistemes d'emmagatzematge
- Sistemes de commutació
- Falla total de tots els equips de l'armari:
- Rebuig al poder
- Falla del sistema de refrigeració
- Factors externs (naturals, humans, etc.)
La duplicació de servidors Oracle implica el principi de funcionament d'Oracle RAC i s'implementa mitjançant una aplicació. La duplicació de les instal·lacions de commutació tampoc és un problema. Però amb la duplicació del sistema d'emmagatzematge, tot no és tan senzill.
L'opció més senzilla és la replicació de dades des del sistema d'emmagatzematge principal fins al de còpia de seguretat. Sincrònic o asíncron, segons les capacitats del sistema d'emmagatzematge. Amb la replicació asíncrona, sorgeix immediatament la qüestió de garantir la coherència de les dades en relació amb Oracle. Però encara que hi hagi integració de programari amb l'aplicació, en tot cas, en cas d'error al sistema d'emmagatzematge principal, caldrà la intervenció manual dels administradors per tal de canviar el clúster a l'emmagatzematge de còpia de seguretat.
Una opció més complexa són els "virtualitzadors" d'emmagatzematge de programari i/o maquinari que eliminaran els problemes de consistència i la intervenció manual. Però la complexitat del desplegament i l'administració posterior, així com el cost molt indecent d'aquestes solucions, espanta a molts.
La solució de matriu AccelStor NeoSapphire™ All Flash és perfecta per a escenaris com ara la recuperació de desastres Cross-Rack utilitzant l'arquitectura Shared-Nothing. Aquest model és un sistema d'emmagatzematge de dos nodes que utilitza la tecnologia patentada FlexiRemap® per treballar amb unitats flash. Gràcies a NeoSapphire™ H710 és capaç d'oferir un rendiment de fins a 600 IOPS@4K d'escriptura aleatòria i 1M+ de IOPS@4K de lectura aleatòria, cosa que no es pot aconseguir quan s'utilitzen sistemes d'emmagatzematge clàssics basats en RAID.
Però la característica principal de NeoSapphire™ H710 és l'execució de dos nodes en forma de casos separats, cadascun dels quals té la seva pròpia còpia de les dades. La sincronització dels nodes es realitza mitjançant la interfície externa InfiniBand. Gràcies a aquesta arquitectura, és possible distribuir nodes a diferents ubicacions a una distància de fins a 100 m, proporcionant així una solució de recuperació de desastres Cross-Rack. Tots dos nodes funcionen de manera totalment sincrònica. Des del costat de l'amfitrió, l'H710 sembla un sistema d'emmagatzematge de controlador dual normal. Per tant, no cal dur a terme cap opció addicional de programari o maquinari ni configuracions especialment complexes.
Si comparem totes les solucions de recuperació de desastres Cross-Rack descrites anteriorment, l'opció d'AccelStor destaca notablement de la resta:
Arquitectura de res compartit AccelStor NeoSapphire™
Sistema d'emmagatzematge “virtualitzador” de programari o maquinari
Solució basada en la replicació
Disponibilitat
Error del servidor
Sense temps d'inactivitat
Sense temps d'inactivitat
Sense temps d'inactivitat
Falla de l'interruptor
Sense temps d'inactivitat
Sense temps d'inactivitat
Sense temps d'inactivitat
Falla del sistema d'emmagatzematge
Sense temps d'inactivitat
Sense temps d'inactivitat
El temps d'inactivitat
Falla total del gabinet
Sense temps d'inactivitat
Sense temps d'inactivitat
El temps d'inactivitat
Cost i complexitat
Cost de la solució
Baix*
Alt
Alt
Complexitat de desplegament
Baixa
Alt
Alt
*AccelStor NeoSapphire™ segueix sent una matriu All Flash, que per definició no costa "3 kopecs", sobretot perquè té una reserva de capacitat doble. Tanmateix, quan es compara el cost final d'una solució basada en ella amb altres similars d'altres proveïdors, el cost es pot considerar baix.
La topologia per connectar els servidors d'aplicacions i els nodes de matriu All Flash tindrà aquest aspecte:
A l'hora de planificar la topologia, també és molt recomanable duplicar commutadors de gestió i interconnectar servidors.
Aquí i més endavant parlarem de la connexió mitjançant Fibre Channel. Si utilitzeu iSCSI, tot serà igual, ajustat per als tipus d'interruptors utilitzats i paràmetres de matriu lleugerament diferents.
Treball preparatori de la matriu
Equips i programari utilitzats
Especificacions del servidor i del commutador
Components
Descripció
Servidors Oracle Database 11g
Dues
Sistema operatiu del servidor
Oracle Linux
Versió de la base de dades Oracle
11 g (RAC)
Processadors per servidor
Dos CPU Intel® Xeon® E16-5 v2667 de 2 nuclis a 3.30 GHz
Memòria física per servidor
128GB
Xarxa FC
FC de 16 Gb/s amb ruta múltiple
FC HBA
Emulex Lpe-16002B
Ports públics d'1 GbE dedicats per a la gestió de clúster
Adaptador Intel Ethernet RJ45
Commutador FC de 16 Gb/s
Brocat 6505
Ports privats de 10 GbE dedicats per a la sincronització de dades
Intel X520
Especificació AccelStor NeoSapphire™ All Flash Array
Components
Descripció
Sistema d'emmagatzematge
Model d'alta disponibilitat NeoSapphire™: H710
Versió d'imatge
4.0.1
Nombre total de unitats
48
Mida de la unitat
1.92TB
Tipus de conducció
SSD
Ports de destinació FC
16 ports de 16 Gb (8 per node)
Ports de gestió
El cable ethernet d'1 GbE es connecta als amfitrions mitjançant un commutador ethernet
Port de batec del cor
El cable Ethernet d'1 GbE que es connecta entre dos nodes d'emmagatzematge
Port de sincronització de dades
Cable InfiniBand de 56 Gb/s
Abans de poder utilitzar una matriu, cal inicialitzar-la. Per defecte, l'adreça de control dels dos nodes és la mateixa (192.168.1.1). Cal connectar-hi un per un i establir noves adreces de gestió (ja diferents) i configurar la sincronització horària, després de la qual els ports de gestió es poden connectar a una única xarxa. Després, els nodes es combinen en un parell HA mitjançant l'assignació de subxarxes per a les connexions d'Interlink.
Un cop finalitzada la inicialització, podeu gestionar la matriu des de qualsevol node.
A continuació, creem els volums necessaris i els publiquem als servidors d'aplicacions.
És molt recomanable crear diversos volums per a Oracle ASM, ja que això augmentarà el nombre d'objectius per als servidors, cosa que en definitiva millorarà el rendiment general (més sobre les cues en un altre ).
Prova de configuració
Nom del volum d'emmagatzematge
Mida del volum
Dades01
200GB
Dades02
200GB
Dades03
200GB
Dades04
200GB
Dades05
200GB
Dades06
200GB
Dades07
200GB
Dades08
200GB
Dades09
200GB
Dades10
200GB
Quadrícula01
1GB
Quadrícula02
1GB
Quadrícula03
1GB
Quadrícula04
1GB
Quadrícula05
1GB
Quadrícula06
1GB
Refer01
100GB
Refer02
100GB
Refer03
100GB
Refer04
100GB
Refer05
100GB
Refer06
100GB
Refer07
100GB
Refer08
100GB
Refer09
100GB
Refer10
100GB
Algunes explicacions sobre els modes de funcionament de la matriu i els processos que es produeixen en situacions d'emergència
El conjunt de dades de cada node té un paràmetre "número de versió". Després de la inicialització inicial, és igual i igual a 1. Si per algun motiu el número de versió és diferent, les dades sempre es sincronitzen de la versió anterior a la més jove, després de la qual s'alinea el número de la versió més jove, és a dir. això vol dir que les còpies són idèntiques. Motius pels quals les versions poden ser diferents:
- Reinici programat d'un dels nodes
- Un accident en un dels nodes per una parada sobtada (alimentació, sobreescalfament, etc.).
- S'ha perdut la connexió InfiniBand amb la impossibilitat de sincronitzar-se
- Un bloqueig en un dels nodes a causa de la corrupció de dades. Aquí haureu de crear un nou grup HA i completar la sincronització del conjunt de dades.
En qualsevol cas, el node que roman en línia augmenta en un el seu número de versió per tal de sincronitzar el seu conjunt de dades després de restablir la connexió amb la parella.
Si es perd la connexió a través de l'enllaç Ethernet, Heartbeat canvia temporalment a InfiniBand i torna en 10 segons quan es restableixi.
Configuració d'amfitrions
Per garantir la tolerància a errors i millorar el rendiment, heu d'habilitar el suport MPIO per a la matriu. Per fer-ho, heu d'afegir línies al fitxer /etc/multipath.conf i, a continuació, reiniciar el servei multipath.
Text ocultdispositius {
dispositiu {
venedor "AStor"
path_grouping_policy "group_by_prio"
path_selector "longitud de la cua 0"
path_checker "tur"
característiques "0"
controlador_maquinari "0"
prior "const"
recuperació immediata
fast_io_fail_tmo 5
dev_loss_tmo 60
user_friendly_names sí
detect_prio sí
rr_min_io_rq 1
no_path_retry 0
}
}
A continuació, per tal que ASM funcioni amb MPIO mitjançant ASMLib, heu de canviar el fitxer /etc/sysconfig/oracleasm i, a continuació, executar /etc/init.d/oracleasm scandisks
Text ocult
# ORACLEASM_SCANORDER: Patrons coincidents per ordenar l'escaneig del disc
ORACLEASM_SCANORDER="dm"
# ORACLEASM_SCANEXCLUDE: Patrons coincidents per excloure discs de l'exploració
ORACLEASM_SCANEXCLUDE="sd"
Nota
Si no voleu utilitzar ASMLib, podeu utilitzar les regles UDEV, que són la base per a ASMLib.
A partir de la versió 12.1.0.2 d'Oracle Database, l'opció està disponible per a la instal·lació com a part del programari ASMFD.
És imprescindible assegurar-se que els discs creats per a Oracle ASM estiguin alineats amb la mida del bloc amb què opera físicament la matriu (4K). En cas contrari, es poden produir problemes de rendiment. Per tant, cal crear volums amb els paràmetres adequats:
parted /dev/mapper/device-name mklabel gpt mkpart primary 2048s 100% align-check òptim 1
Distribució de bases de dades entre els volums creats per a la nostra configuració de prova
Nom del volum d'emmagatzematge
Mida del volum
Mapeig de LUN de volum
Detall del dispositiu de volum ASM
Mida de la unitat d'assignació
Dades01
200GB
Assigna tots els volums d'emmagatzematge al sistema d'emmagatzematge de tots els ports de dades
Redundància: normal
Nom: DGDATA
Finalitat: Fitxers de dades
4MB
Dades02
200GB
Dades03
200GB
Dades04
200GB
Dades05
200GB
Dades06
200GB
Dades07
200GB
Dades08
200GB
Dades09
200GB
Dades10
200GB
Quadrícula01
1GB
Redundància: normal
Nom: DGGRID1
Finalitat: Quadrícula: CRS i Votació
4MB
Quadrícula02
1GB
Quadrícula03
1GB
Quadrícula04
1GB
Redundància: normal
Nom: DGGRID2
Finalitat: Quadrícula: CRS i Votació
4MB
Quadrícula05
1GB
Quadrícula06
1GB
Refer01
100GB
Redundància: normal
Nom: DGRADO1
Propòsit: refer el registre del fil 1
4MB
Refer02
100GB
Refer03
100GB
Refer04
100GB
Refer05
100GB
Refer06
100GB
Redundància: normal
Nom: DGRADO2
Propòsit: refer el registre del fil 2
4MB
Refer07
100GB
Refer08
100GB
Refer09
100GB
Refer10
100GB
Configuració de la base de dades
- Mida del bloc = 8K
- Espai d'intercanvi = 16 GB
- Desactiva AMM (gestió automàtica de memòria)
- Desactiva les pàgines enormes transparents
Altres configuracions
# vi /etc/sysctl.conf
✓ fs.aio-max-nr = 1048576
✓ fs.file-max = 6815744
✓ kernel.shmmax 103079215104
✓ kernel.shmall 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 # no configureu això si feu servir Linux x86
✓ vm.vfs_cache_pressure=200
✓ vm.nr_hugepages = 57000
# vi /etc/security/limits.conf
✓ graella suau nproc 2047
✓ graella dura nproc 16384
✓ graella suau nofile 1024
✓ graella dur nofile 65536
✓ graella suau pila 10240
✓ graella de pila dura 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
✓ soft memlock 120795954
✓ Memlock dur 120795954
sqlplus "/as sysdba"
alterar el conjunt de processos del sistema = 2000 abast = fitxer sp;
altera el conjunt del sistema open_cursors=2000 scope=spfile;
altera el conjunt del sistema session_cached_cursors=300 scope=spfile;
altera el conjunt del sistema db_files=8192 scope=spfile;
Prova de fracàs
Amb finalitats de demostració, es va utilitzar HammerDB per emular una càrrega OLTP. Configuració de HammerDB:
Nombre de magatzems
256
Total de transaccions per usuari
1000000000000
Usuaris virtuals
256
El resultat va ser un TPM de 2.1 milions, que està lluny del límit de rendiment de la matriu , però és un "sostre" per a la configuració de maquinari actual dels servidors (principalment a causa dels processadors) i el seu nombre. L'objectiu d'aquesta prova encara és demostrar la tolerància a fallades de la solució en conjunt, i no aconseguir el màxim rendiment. Per tant, simplement ens basarem en aquesta figura.
Prova de fallada d'un dels nodes
Els amfitrions van perdre part dels camins cap a l'emmagatzematge, continuant treballant amb els restants amb el segon node. El rendiment va baixar durant uns segons a causa de la reconstrucció dels camins i després va tornar a la normalitat. No hi va haver interrupció del servei.
Prova de fallada de l'armari amb tots els equips
En aquest cas, el rendiment també va baixar durant uns segons a causa de la reestructuració dels camins, i després va tornar a la meitat del valor original. El resultat es va reduir a la meitat respecte a l'inicial a causa de l'exclusió d'un servidor d'aplicacions del funcionament. Tampoc hi va haver interrupció del servei.
Si cal implementar una solució de recuperació de desastres Cross-Rack tolerant a errors per a Oracle a un cost raonable i amb poc esforç de desplegament/administració, llavors Oracle RAC i l'arquitectura treballen junts. serà una de les millors opcions. En lloc d'Oracle RAC, hi pot haver qualsevol altre programari que proporcioni agrupació en clúster, el mateix DBMS o sistemes de virtualització, per exemple. El principi de construcció de la solució continuarà sent el mateix. I el resultat final és zero per a RTO i RPO.
Font: www.habr.com