O teorema CAP é a pedra angular da teoría de sistemas distribuídos. Por suposto, a polémica ao seu redor non cede: as definicións nela non son canónicas, e non hai unha proba estrita... Non obstante, firmemente sobre as posicións do sentido común™ cotián, entendemos intuitivamente que o teorema é certo.
O único que non é obvio é o significado da letra "P". Cando o clúster está dividido, decide se non responde ata que se alcance o quórum ou se devolve os datos dispoñibles. Dependendo dos resultados desta elección, o sistema clasifícase como CP ou AP. Cassandra, por exemplo, pode comportarse de calquera xeito, dependendo nin sequera da configuración do clúster, senón dos parámetros de cada solicitude específica. Pero se o sistema non é "P" e se divide, entón que?
A resposta a esta pregunta é algo inesperada: un clúster de CA non pode dividirse.
Que tipo de clúster é este que non pode dividirse?
Un atributo indispensable de tal clúster é un sistema de almacenamento de datos compartido. Na gran maioría dos casos, isto significa conectarse a través dunha SAN, o que limita o uso de solucións de CA ás grandes empresas capaces de manter unha infraestrutura SAN. Para que varios servidores funcionen cos mesmos datos, é necesario un sistema de ficheiros agrupados. Estes sistemas de ficheiros están dispoñibles nas carteiras HPE (CFS), Veritas (VxCFS) e IBM (GPFS).
Oracle RAC
A opción Real Application Cluster apareceu por primeira vez en 2001 co lanzamento de Oracle 9i. Neste clúster, varias instancias de servidor funcionan coa mesma base de datos.
Oracle pode traballar tanto cun sistema de ficheiros en clúster como coa súa propia solución: ASM, xestión automática de almacenamento.
Cada copia leva o seu propio diario. A transacción é executada e comprometida por unha instancia. Se unha instancia falla, un dos nodos (instancias) de clúster superviventes le o seu rexistro e restaura os datos perdidos, garantindo así a dispoñibilidade.
Todas as instancias manteñen a súa propia caché e as mesmas páxinas (bloques) poden estar nas cachés de varias instancias ao mesmo tempo. Ademais, se unha instancia necesita unha páxina e está na caché doutra instancia, pode obtela do seu veciño usando o mecanismo de fusión da caché en lugar de ler desde o disco.
Pero que pasa se unha das instancias precisa cambiar datos?
A peculiaridade de Oracle é que non ten un servizo de bloqueo dedicado: se o servidor quere bloquear unha fila, entón o rexistro de bloqueo colócase directamente na páxina de memoria onde se atopa a fila bloqueada. Grazas a este enfoque, Oracle é o campión do rendemento entre as bases de datos monolíticas: o servizo de bloqueo nunca se converte nun pescozo de botella. Pero nunha configuración de clúster, tal arquitectura pode levar a un intenso tráfico de rede e bloqueos.
Unha vez bloqueado un rexistro, unha instancia notifica a todas as demais instancias que a páxina que almacena ese rexistro ten unha retención exclusiva. Se outra instancia precisa cambiar un rexistro na mesma páxina, debe esperar ata que se realicen os cambios na páxina, é dicir, a información do cambio escríbese nun diario no disco (e a transacción pode continuar). Tamén pode ocorrer que unha páxina se cambie secuencialmente por varias copias, e despois ao escribir a páxina no disco terás que descubrir quen almacena a versión actual desta páxina.
A actualización aleatoria das mesmas páxinas en distintos nodos RAC fai que o rendemento da base de datos caia drasticamente, ata o punto de que o rendemento do clúster pode ser inferior ao dunha única instancia.
O uso correcto de Oracle RAC é particionar fisicamente os datos (por exemplo, mediante un mecanismo de táboa particionada) e acceder a cada conxunto de particións a través dun nodo dedicado. O obxectivo principal do RAC non era a escala horizontal, senón garantir a tolerancia ás fallas.
Se un nodo deixa de responder a un latido do corazón, entón o nodo que o detectou primeiro inicia un procedemento de votación no disco. Se o nodo que falta non se indica aquí, entón un dos nodos asume a responsabilidade da recuperación de datos:
- "conxela" todas as páxinas que estaban na caché do nodo que falta;
- le os rexistros (refacer) do nodo que falta e volve aplicar os cambios rexistrados nestes rexistros, comprobando simultaneamente se outros nodos teñen versións máis recentes das páxinas que se están modificando;
- retrotrae as transaccións pendentes.
Para simplificar o cambio entre nodos, Oracle ten o concepto de servizo: unha instancia virtual. Unha instancia pode servir varios servizos e un servizo pode moverse entre nodos. Unha instancia de aplicación que serve unha determinada parte da base de datos (por exemplo, un grupo de clientes) funciona cun servizo e o servizo responsable desta parte da base de datos móvese a outro nodo cando falla un nodo.
IBM Pure Data Systems for Transactions
Unha solución de clúster para DBMS apareceu na carteira de Blue Giant en 2009. Ideoloxicamente, é o sucesor do clúster Parallel Sysplex, construído sobre equipos "normales". En 2009, DB2 pureScale lanzouse como unha suite de software e, en 2012, IBM ofreceu un dispositivo chamado Pure Data Systems for Transactions. Non se debe confundir con Pure Data Systems for Analytics, que non é máis que un Netezza renomeado.
A primeira vista, a arquitectura pureScale é semellante a Oracle RAC: do mesmo xeito, varios nodos están conectados a un sistema de almacenamento de datos común e cada nodo executa a súa propia instancia de DBMS coas súas propias áreas de memoria e rexistros de transaccións. Pero, a diferenza de Oracle, DB2 ten un servizo de bloqueo dedicado representado por un conxunto de procesos db2LLM*. Nunha configuración de clúster, este servizo colócase nun nodo separado, que se denomina instalación de acoplamento (CF) en Parallel Sysplex e PowerHA en Pure Data.
PowerHA ofrece os seguintes servizos:
- xestor de bloqueo;
- caché global do buffer;
- área de comunicacións entre procesos.
Para transferir datos de PowerHA aos nodos da base de datos e viceversa, utilízase acceso remoto á memoria, polo que a interconexión do clúster debe admitir o protocolo RDMA. PureScale pode usar tanto Infiniband como RDMA a través de Ethernet.
Se un nodo necesita unha páxina, e esta páxina non está na caché, entón o nodo solicita a páxina na caché global e só se non está alí, lea desde o disco. A diferenza de Oracle, a solicitude diríxese só a PowerHA e non aos nós veciños.
Se unha instancia vai cambiar unha fila, bloqueaa en modo exclusivo e a páxina onde se atopa a fila en modo compartido. Todos os bloqueos están rexistrados no xestor global de bloqueos. Cando se completa a transacción, o nodo envía unha mensaxe ao xestor de bloqueos, que copia a páxina modificada na caché global, libera os bloqueos e invalida a páxina modificada nas cachés doutros nodos.
Se a páxina na que se atopa a fila modificada xa está bloqueada, entón o xestor de bloqueos lerá a páxina modificada da memoria do nodo que fixo o cambio, liberará o bloqueo, invalidará a páxina modificada nos cachés doutros nodos e dálle o bloqueo de páxina ao nodo que o solicitou.
As páxinas "sucias", é dicir, modificadas, pódense escribir no disco tanto desde un nodo normal como desde PowerHA (castout).
Se falla un dos nodos pureScale, a recuperación limítase só a aquelas transaccións que aínda non se completasen no momento do fallo: as páxinas modificadas por ese nodo nas transaccións completadas están na caché global de PowerHA. O nodo reinicia nunha configuración reducida nun dos servidores do clúster, retrotrae as transaccións pendentes e libera os bloqueos.
PowerHA execútase en dous servidores e o nodo mestre replica o seu estado de forma sincrónica. Se o nodo PowerHA principal falla, o clúster segue funcionando co nodo de copia de seguridade.
Por suposto, se accede ao conxunto de datos a través dun único nodo, o rendemento global do clúster será maior. PureScale pode incluso notar que unha determinada área de datos está a ser procesada por un nodo e, a continuación, todos os bloqueos relacionados con esa área serán procesados localmente polo nodo sen comunicarse con PowerHA. Pero en canto a aplicación intente acceder a estes datos a través doutro nodo, reanudarase o procesamento de bloqueo centralizado.
As probas internas de IBM sobre unha carga de traballo do 90 % de lectura e 10 % de escritura, que é moi semellante ás cargas de traballo de produción do mundo real, mostran unha escala case lineal ata 128 nodos. As condicións das probas, por desgraza, non se revelan.
HPE NonStop SQL
A carteira de Hewlett-Packard Enterprise tamén ten a súa propia plataforma altamente dispoñible. Esta é a plataforma NonStop, lanzada ao mercado en 1976 por Tandem Computers. En 1997, a compañía foi adquirida por Compaq, que á súa vez se fusionou con Hewlett-Packard en 2002.
NonStop úsase para crear aplicacións críticas, por exemplo, HLR ou procesamento de tarxetas bancarias. A plataforma preséntase en forma de complexo de software e hardware (appliance), que inclúe nodos informáticos, un sistema de almacenamento de datos e equipos de comunicación. A rede ServerNet (nos sistemas modernos - Infiniband) serve tanto para o intercambio entre nodos como para o acceso ao sistema de almacenamento de datos.
As primeiras versións do sistema usaban procesadores propietarios que estaban sincronizados entre si: todas as operacións eran realizadas de forma sincronizada por varios procesadores e, en canto un dos procesadores cometeu un erro, desactivouse e o segundo seguiu funcionando. Máis tarde, o sistema pasou a procesadores convencionais (primeiro MIPS, despois Itanium e finalmente x86), e comezaron a utilizar outros mecanismos para a sincronización:
- mensaxes: cada proceso do sistema ten un xemelgo "sombra", ao que o proceso activo envía periodicamente mensaxes sobre o seu estado; se o proceso principal falla, o proceso de sombra comeza a funcionar desde o momento determinado pola última mensaxe;
- votación: o sistema de almacenamento ten un compoñente hardware especial que acepta múltiples accesos idénticos e só os executa se os accesos coinciden; En lugar da sincronización física, os procesadores funcionan de forma asíncrona e os resultados do seu traballo compáranse só nos momentos de E/S.
Desde 1987, un DBMS relacional está a executarse na plataforma NonStop: primeiro SQL/MP, e máis tarde SQL/MX.
Toda a base de datos está dividida en partes, e cada parte é responsable do seu propio proceso de Data Access Manager (DAM). Ofrece mecanismos de gravación, almacenamento en caché e bloqueo de datos. O procesamento de datos realízao Procesos de Executor Server que se executan nos mesmos nodos que os correspondentes xestores de datos. O planificador SQL/MX divide as tarefas entre os executores e agrega os resultados. Cando é necesario realizar cambios acordados, utilízase o protocolo de commit en dúas fases proporcionado pola biblioteca TMF (Transaction Management Facility).
NonStop SQL pode priorizar os procesos para que as consultas analíticas longas non interfiran coa execución das transaccións. Non obstante, o seu propósito é precisamente o procesamento de transaccións curtas, e non analíticas. O desenvolvedor garante a dispoñibilidade do clúster NonStop ao nivel de cinco "nove", é dicir, o tempo de inactividade é de só 5 minutos ao ano.
SAP-HANA
A primeira versión estable do DBMS de HANA (1.0) tivo lugar en novembro de 2010 e o paquete SAP ERP cambiou a HANA en maio de 2013. A plataforma baséase en tecnoloxías adquiridas: TREX Search Engine (busca en almacenamento columnar), P*TIME DBMS e MAX DB.
A palabra "HANA" en si é un acrónimo, High performance ANalytical Appliance. Este DBMS ofrécese en forma de código que se pode executar en calquera servidor x86, non obstante, as instalacións industriais só están permitidas en equipos certificados. Solucións dispoñibles de HP, Lenovo, Cisco, Dell, Fujitsu, Hitachi, NEC. Algunhas configuracións de Lenovo incluso permiten o funcionamento sen SAN: o papel dun sistema de almacenamento común é desempeñado por un clúster GPFS nos discos locais.
A diferenza das plataformas enumeradas anteriormente, HANA é un DBMS en memoria, é dicir, a imaxe de datos primaria almacénase na RAM e só se escriben no disco os rexistros e as instantáneas periódicas para a súa recuperación en caso de desastre.
Cada nodo do clúster HANA é responsable da súa propia parte dos datos e o mapa de datos gárdase nun compoñente especial: o servidor de nomes, situado no nodo coordinador. Os datos non se duplican entre os nodos. A información de bloqueo tamén se almacena en cada nodo, pero o sistema ten un detector de bloqueo global.
Cando un cliente de HANA se conecta a un clúster, descarga a súa topoloxía e pode acceder directamente a calquera nodo, dependendo dos datos que necesite. Se unha transacción afecta aos datos dun só nodo, entón pode ser executada localmente por ese nodo, pero se os datos de varios nodos cambian, o nodo iniciador contacta co nodo coordinador, que abre e coordina a transacción distribuída, comprometíndoa mediante un protocolo de commit optimizado en dúas fases.
O nodo coordinador duplícase, polo que, se o coordinador falla, o nodo de copia de seguridade toma o relevo inmediatamente. Pero se falla un nodo con datos, a única forma de acceder aos seus datos é reiniciar o nodo. Como regra xeral, os clústeres de HANA manteñen un servidor de reserva para reiniciar un nodo perdido o máis rápido posible.
Fonte: www.habr.com