Introducción á Alta Dispoñibilidade: Diferenzas entre revisións
(Non se amosan 14 revisións do historial feitas polo mesmo usuario.) | |||
Liña 27: | Liña 27: | ||
====Fallos no Subministro Eléctrico.==== |
====Fallos no Subministro Eléctrico.==== |
||
O subministro eléctrico é a base do funcionamento dos sistemas de tratamento de información. As variacións bruscas poden danar o equipamento, e a súa falta provoca a parada do sistema |
O subministro eléctrico é a base do funcionamento dos sistemas de tratamento de información. As variacións bruscas poden danar o equipamento, e a súa falta provoca a parada do sistema, polo que é necesario o uso de [[Seguridade_Pasiva_e_Física#Sistemas_de_Alimentaci.C3.B3n_Ininterrumpida_.28SAI.29|SAI]]. |
||
Os problemas ante o subministro eléctrico poden ser debidos a fallos nas fontes de alimentación dos equipos (debemos dotalos de fontes redundantes), fluctuacións de tensión (sobretensións, caídas e baixadas) e cortes de subministro (cortes e microcortes). Para resolver este tipo de problemas se empregan os Sistemas de Alimentación Ininterrumpida (SAI ou [[wikipedia:Uninterruptible_power_supply|UPS]]). |
|||
Un SAI é un sistema de almacenamento eléctrico, que permite o almacenamento de enerxía para ser utilizada en caso de cortes. Adicionalmente, o SAI proporciona unha fonte enerxética estable, independentemente da calidade do subministro xeral. Os dispositivos a protexer irán enchufados ao SAI, que lles suminstrará enerxía obtida da rede xeral, ou no seu caso, das súas baterías. |
|||
Os SAI ofrecen distintos tipos de conectores, alguns únicamente ofrecen protección eléctrica, mentras que outros tamén subministran electricidade en caso de cortes. Estes conectores poden ser para [[wikipedia:Modular_connector|RJ-45]], [[wikipedia:Modular_connector|RJ-11]], USB ou tomas eléctricas de tipo [[wikipedia:IEC_60320|IEC]] ou [[wikipedia:Schuko|Schuko]]. |
|||
=====Tipos de SAI===== |
|||
En función da tecnoloxía empregada e a calidade da súa saída os SAI actualmente se clasifican en: |
|||
:*''OFFLINE:'' Baixa gama. A protección ofrecida depende do seu tipo exacto. No momento da baixada de tensión producida por un corte eléctrico, este tipo de SAI entra en funcionamento, pero tarda en reaccionar (uns 25ms) producíndose un pequeño corte eléctrico (microcorte) que normalmente non ten ningún efecto no equipamento habitual (salvo en equipos especialmente sensibles). Nunha escala de protección de 1 a 100, sería un 40. |
|||
:*''INLINE'' ou ''LINE INTERACTIVE'': Este tipo de SAI conten un transformador que é capaz de subministrar a diferencia de voltaxe en caso de caída de tensión ou de recortar voltaxe na sáida en caso dunha subida. Dependendo da tecnoloxía empregada é posible que tamén se produzan microcortes eléctricos. O nivel de protección nunha escala de 1 a 100 sería entre 70 e 90. |
|||
:*''ONLINE'' ou ''DE DOBRE CONVERSIÓN'': É a gama alta, e o precio e moito maior, aínda que as baterías son de máis duración o que pode compensar á larga. A tecnoloxía é similar a empregada nos SAI ''line interactive'', pero subministran maior potencia e estan en funcionamento continuo evitando completamente os microcortes e proporcionando unha corrente estable en todo momento. Mentras que os SAI offline e inline simplemente filtran a corrente de entrada, este tipo de SAI aíllan completamente o equipamento do subministro eléctrico principal. |
|||
=====Potencia===== |
|||
A potencia que precisamos que subministre un SAI depende directamente do equipamento que necesitamos conectar. O problema é que os fabricates dos SAI especifican a potencia en [[wikipedia:Volt-ampere|voltiamperios (VA)]], que é a potencia aparente tamén chamada ''potencia efectiva'' ou ''eficaz'', mentras que o consumo dos equipos se indica en potencia real medida en [[wikipedia:Watt|Vatios]]. Para averiguar o pico máximo de consumo dun equipamento (a ''potencia efectiva''), se multiplicará a súa potencia real (''en Vatios'') por '''1,4'''. (En realidade este valor de 1,4 depende da eficiencia enerxética do dispositivo. A maior eficiencia, menor será o factor). |
|||
{{boxinfo|A potencia real (''en Vatios'') dos dispositivos podemos obtela da información do fabricante, ou tomando medidas mediante un medidor de potencia ou de intensidade (pinza amperimétrica). Se recomenda non situar cargas maiores ao 70% da potencia subminsitrada polo SAI. }} |
|||
=====Monitorización===== |
|||
Os fabricantes dos SAI proporcionan habitualmente ferramentas de monitorización do funcionamento do SAI que permiten vixiar parámetros como o estado das baterías, o nivel de carga, o nivel de corrente de entrada e de saída, etc. Tamén permiten configurar o comportamento do equipamento cando a carga do SAI se agota, sendo necesario programar paradas limpas do sistema e notificacións ao administrador. As conexións dende as que o sistema toma os datos do SAI son habitualmente USB ou serie. |
|||
En Linux existe un software de monitorización de SAI estándar para unha gran cantidade de modelos, evitando a dependencia do software específico do fabricante chamado '''NUT (''Network UPS Tools'')''', que proporciona a posibilidade de acceso á monitorización do SAI a través da rede permitindo que varios equipos da rede tomen as medidas oportunas en caso de fallo de alimentación. |
|||
A configuración básica de Nut en Debian realízase nos seguintes ficheiros: |
|||
;/etc/nut/nut.conf: Fundamentalmente establece o modo de funcionamento de nut. |
|||
;/etc/nut/ups.conf: Aquí se configura o nome do SAI e o seu tipo e driver utilizado. |
|||
;/etc/nut/upsd.users: Usuarios do SAI. Terán acceso aos datos de monitorización e control do SAI. |
|||
;/etc/nut/upsmon.conf: Datos de acceso ao SAI para a súa monitorización. |
|||
Para a monitorización do SAI existen varias aplicacións con entorno gráfico, como ''knutclient'', ''python-nut'' ou ''nut-monitor'', e o módulo CGI ''nut-cgi'', para a monitorización web. |
|||
====Fallos nas Comunicacións.==== |
====Fallos nas Comunicacións.==== |
||
Liña 185: | Liña 154: | ||
Algúns sistemas para implantar clustering HA son: |
Algúns sistemas para implantar clustering HA son: |
||
*[[wikipedia: |
*[[wikipedia:Linux-HA|Heartbeat]] - E un monitor con unha capacidade limitada a hora de reconfigurar os servicios. É util para sistemas simples en que únicamente dispoñemos de 2 nodos monitorizados con granularidade de servidor. |
||
*Heartbeat+Pacemaker - Se combina Heartbeat con Pacemaker, que nos ofrece granuralidade de servizo e xestión de múltiples nodos no clúster. |
*Heartbeat+[[wikipedia:Pacemaker_(software)|Pacemaker]] - Se combina Heartbeat con Pacemaker, que nos ofrece granuralidade de servizo e xestión de múltiples nodos no clúster. |
||
*Corosync+Pacemaker - O monitor a utilizar e Corosync, que ofrece funcionalidades similares a Heartbeat pero non permite a xestión de clústeres sen Pacemaker. |
*[[wikipedia:Corosync|Corosync]]+Pacemaker - O monitor a utilizar e Corosync, que ofrece funcionalidades similares a Heartbeat pero non permite a xestión de clústeres sen Pacemaker. |
||
*[http://www.sourceware.org/cluster/cman/ CMAN] - é un sistema parte da [[wikipedia:Red_Hat_cluster_suite|RedHat Cluster Suite]] para crear clusters de alta dispoñibilidade. Principalmente actúa como xestor de ''quorum'', que é un sistema de puntuación para decidir qué nodo do cluster se fará cargo do servizo. Se encargará de iniciar e parar todos os compoñentes necesarios para a operación do cluster facemdo unha función similar a '''pacemaker'''. |
|||
Un dos problemas existentes cando un servidor ten que reemplazar a outro e continuar co servizo no mesmo punto é a xestión da información. Todos os nodos do cluster ofrecendo o servizo necesitan ter acceso aos mesmos datos. Existen dúas formas de acadar este obxectivo: |
|||
*Almacenamento Remoto: Os servidores almacenan a información en un sistema de almacenamento compartido como un SAN ou NAS. |
|||
*[[wikipedia:Distributed Replicated Block Device|DRBD (Distributed Replicated Block Device)]]: É un sistema no que se pode realizar un RAID-1 entre dispositivos de bloques conectados en rede. Deste xeito, dous servidores poden obter unha copia exacta dos mesmos datos en todo momento. |
|||
{{boxinfo|[[wikipedia:Distributed Replicated Block Device|DRBD (Distributed Replicated Block Device)]] se emprega habitualmente na creación de ''clusters'' de alta dispoñibilidade, xa que da a posibilidade de que un servidor de reserva continúe co servicio de xeito automático ao dispoñer dunha copia da información completamente actualizada.}} |
{{boxinfo|[[wikipedia:Distributed Replicated Block Device|DRBD (Distributed Replicated Block Device)]] se emprega habitualmente na creación de ''clusters'' de alta dispoñibilidade, xa que da a posibilidade de que un servidor de reserva continúe co servicio de xeito automático ao dispoñer dunha copia da información completamente actualizada.}} |
Revisión actual feita o 28 de xuño de 2014 ás 21:16
Introducción
A alta dispoñibilidade consiste na implementación de sistemas e o deseño de servizos de xeito que se garantice un tempo preestablecido de dispoñibilidade. Normalmente, este tempo de dispoñibilidade se mide en tempo de funcionamento (uptime) ao longo do ano, chegando a acordos de servicio que permiten un tempo de parada máximo mensual.
Estes tempos de parada fan referencia tanto a paradas planificadas (as precisas para o mantemento do sistema, como backups, actualizacións ou reconfiguracións) ou non planificadas (fallos no servizo). No caso dos fallos de servizo, son importantes os parámetros de ETR (Estimated Time of Repair) e RTO (Recovery Time Objective) que proporciona a empresa.
Sistemas de Alta Dispoñibilidade.
Para a implementación dun sistema de alta dispoñibilidade resulta imprescindible garantizar o nivel de servizo acordado, polo que habitualmente se recurre a virtualización (que permite transportar fácilmente o servizo de un servidor a outro, ou incluso entre centros de procesamento de datos distintos) e a redundancia.
A redundancia permite a recuperación case inmediata en caso de fallo, e se pode realizar en varios sistemas e niveis.
- A nivel de alimentación (fontes redundantes, suministro eléctrico diferenciado, xeradores de emerxencia...)
- A nivel de almacenamento de datos (RAID, DRBD ...)
- A nivel de comunicacións (múltiples proveedores de acceso a rede, bonding nos servicios críticos...)
- A nivel de procesamento, mantendo servidores de reserva en caso de fallo do primario (clústering de HA)
Un sistema de alta dispoñibilidade, en definitiva, debe dispoñer de varios sistemas de tolerancia a fallos que garanticen o servizo baixo calqueira circunstancia.
Tolerancia a Fallos.
O motivo principal da ubicación dos sistemas informáticos en CPD (Centos de Procesamento de Datos) é facilitar a seguridade de xeito que se poida conseguir unha alta dispoñibilidade do sistema. Sen embargo, en ocasións é imposible evitar que se produza un problema, polo que é necesario ter previstas medidas que permitan solventalo no menor prazo de tempo posible e reducir o seu impacto. O uso de CPD de respaldo nunha ubicación distante é unha destas medidas que permiten manter o servizo no caso de que se producira un gran desastre (explosión, terremoto...), pero existen medidas de menor entidade que se deben ter en conta.
Fallos de Hardware.
Un dos posibles problemas é o fallo do propio equipamento hardware que ofrece o servizo (servidores de datos e procesamento, discos fixos... etc). A única solución nestes casos reside na existencia de equipamento de respaldo que releve no servizo ao hardware danado, sendo necesaria unha monitorización constante do sistema para elexir en qué momento é necesario que a reserva pase a estar activa, e activar o aviso (via mensaxe telefónica ou correo electrónico) ao responsable.
Existen diversos tipos de monitorización e mantemento de equipamento de reserva segundo o tipo de hardware a respaldar, pero nos sistemas de procesamento habitualmente se recurre aos cluster de alta dispoñibilidade.
Fallos no Subministro Eléctrico.
O subministro eléctrico é a base do funcionamento dos sistemas de tratamento de información. As variacións bruscas poden danar o equipamento, e a súa falta provoca a parada do sistema, polo que é necesario o uso de SAI.
Fallos nas Comunicacións.
Os centros de procesamento de datos precisan de liñas de comunicación fiables que manteñan en todo momento a accesibilidade dos datos, polo tanto é imprescindible adoptar estratexias que nos protexan ante este tipo de fallos.
A solución a posibles fallos nas liñas de comunicacións está na redundancia. É preciso dispoñer de varias liñas de comunicación alternativas, preferiblemente de operadores e tecnoloxías distintas, de xeito que o fallo de unha non supoña o aillamento do sistema. Para xestionar estas liñas se pode recurrir a agregación de enlaces ou bonding que permite ademáis de distribuír a carga das comunicacións entre os distintos enlaces (balanceo de carga), manter o funcionamento en caso de caída dun enlace.
O Bonding ou Link Aggregation é a posibilidade de que varios interfaces de rede funcionen como un so, proporcionando ao mesmo tempo balanceo de carga (case dobrando o ancho de banda) e alta dispoñibilidade (en caso de caída dun enlace, a comunicación continúa polo resto). As solucións para a implementación do Link Aggregation dependían de cada fabricante ata que o IEEE 802.3 deseñou o estándar 803.2ad e o protocolo LACP (Link Aggregation Control Protocol), permitindo a agregación dinámica de enlaces.
Nos sistemas Windows, a agregación de enlaces depende do soporte 803.2ad e das ferramentas subministradas polos fabricantes dos sistemas de rede (tarxetas de rede e switches). En Linux, o kernel permite o bonding utilizando distintas estratexias:
- Round Robin - Os paquetes de datos se transmiten de xeito secuencial, dende o primeiro enlace do bond ata o último, proporcionando tolerancia a fallos e balanceo de carga. Normalmente é preciso que os portos do switch pertencentes ao bond estén agrupados xuntos, polo que o switch ten que soportar Port Trunking, ou Etherchannel.
- Active Backup - Únicamente un enlace está activo. Si o enlace activo falla, outro entra en funcionamento, proporcionando únicamente tolerancia a fallos. Non require de soporte nin configuración especial no switch.
- Xor - Selecciona sempre o mesmo escravo para unha dirección MAC destiño. Proporciona tolerancia a fallos e balanceo de carga. É preciso que os portos do switch pertencentes ao bond estén agrupados xuntos, polo que o switch ten que soportar Port Trunking, ou Etherchannel.
- Broadcast - Transmite todo por todos os enlaces. Únicamente proporciona tolerancia a fallos. É preciso que os portos do switch pertencentes ao bond estén agrupados xuntos, polo que o switch ten que soportar Port Trunking, ou Etherchannel.
- IEEE 802.3ad LACP - Crea grupos de agregación que comparten a mesma velocidade e características duplex. Os escravos do grupo activo actúan de acordo a especificación 802.3ad. Precisa que o switch soporte 802.3ad, e a configuración concreta dos portos implicados depende do modelo.
- Adaptative Transmit Load Balancing - O tráfico de saída se distribúe de acordo coa carga actual (relativa á velocidade de procesamento) en cada escravo. O tráfico de entrada se recibe polo escravo activo. Si o enlace receptor falla, outro enlace toma a dirección MAC do enlace fallido. Proporciona tolerancia a fallos e balanceamento de carga, e non precisa de soporte por parte dos switches.
- Adaptative Load Balancing - E similar ao anterior, pero tamén balancea o tráfico de entrada manipulando a negociación ARP. Tamén proporciona tolerancia a fallos e balanceo de carga sen precisar soporte por parte do switch. O inconvinte é que se precisa que o driver sexa capaz de modificar a dirección MAC da tarxeta, o que normalmente non soportan as máis baratas.
Si as ethernet a unir están unidas ao mesmo switch, non existe diferencia na configuración para tolerancia a fallos que para balanceo de carga, sendo posible obter ambas sen penalización. No caso en que as tarxetas de rede estén conectadas a switches diferentes únicamente ten sentido o uso dos modos Active-Backup ou Broadcast.
Para configurar o bonding en Linux, o primeiro é cargar o módulo bonding. Para elo, crearemos un ficheiro en /etc/modprobe.d, ou ben editaremos /etc/modprobe.conf ou /etc/modules.conf, dependendo do sistema, co seguinte contido: alias bondN bonding options bonding mode=x
Donde N é o número do interface bond a crear (0 o primeiro) e x é un número entre 0 e 6, referíndose por orde os modos de bonding explicados anteriormente. Tamén é posible indicarlle o modo de monitorización para a detección de fallos nos enlaces.
Linux soporta dous modos de monitorización de fallos nas tarxetas de rede:
- ARP (options bonding mode=x arp_interval=XX arp_ip_target= ip1,ip2,ip3 …) - Este modo envía peticións ARP aos hosts indicados en arp_ip_target utilizando a resposta para determiñar si un enlace está caído. Este modo depende de que o driver da tarxeta actualice correctamente os campos de ilast_rx e trans_start. O parámetro arp_interval indica cada cantos milisegundos se verifican os enlaces, o valor típico é de 60ms.
- MII (options bonding mode=x miimon=XX) - E o modo por defecto. Verifica o estado da portadora no enlace, normalmente consultando ao driver. Si se especifica o parámetro adicional use_carrier=0, a detección se realiza consultando os rexistros do driver, e si falla , utilizando ethtool. miimon indica cada cantos milisegundos se realiza a verificación dos enlaces. O valor típico é 100ms.
En Debian, a configuración e moi simple. Precisamos da aplicación ifenslave-2.6 configurando o bonding directamente en /etc/network/interfaces. Un exemplo con tres interfaces é o seguinte:
auto bond0
iface bond0 inet static
address 192.168.122.2
netmask 255.255.255.0
network 192.168.122.0
gateway 192.168.122.1
slaves eth0 eth1 eth2
# Os mode pode ser: balance-rr active-backup balance-xor broadcast 802.3ad balance-tlb balance-alb
bond-mode balance-tlb
bond-miimon 100
bond-downdelay 200
bond-updelay 200
Fallos no sistema de Almacenamento.
Outro dos fallos críticos nun centro de procesamento de datos é a posibilidade de fallo nos sistemas de almacenamento. Unha das solucións máis empregadas é o uso de varios discos de xeito simultáneo, tanto para aumentar a velocidade de acceso como para manter o acceso aos datos en caso de posibles fallos nas unidades. Son os coñecidos como sistemas RAID (Redundant Array Of Independent Disks).
Tipos de RAID
Os niveis de RAID máis comúns son os seguintes:
- RAID 0 - Proporciona maior velocidade de lectura e escritura. Consiste no reparto da información entre varios discos que funcionan como un so, e normalmente se implementa con dous discos.
- RAID 1 - Tamén chamada espello. Copia os datos en dous ou máis discos que funcionan como unha unidade única. Proporciona seguridade contra os fallos, xa que no caso de fallo dun disco físico, a información pode ser accedida no resto. A velocidade de lectura tamén se ve incrementada, xa que se pode leer a información de varios discos de xeito simultáneo.
- RAID2, RAID 3, RAID 4 - Estos sistemas reparten bits, bytes e bloques respectivamente entre os discos do RAID, utilizando discos adicionais para almacenar códigos de paridade para correxir posibles erros. Proporcionan seguridade contra os fallos e un gran aumento na velocidade de lectura e escritura.
- RAID 5 - Divide os datos e a información de paridade entre os discos a nivel de bloque. Necesita un mínimo de 3 discos. Proporciona seguridade contra os fallos e aumento na velocidade de lectura e escritura. O fallo de dous discos provoca a perda dos datos.
- RAID 6: - E similar ao 5, pero calculando dous datos de paridade, co que poden recuperarse fallos de máis de dous discos. A velocidade de escritura e menor que no RAID 5 debido a necesidade de calcular dous valores de paridade.
- RAID 5E e RAID 6E - Son RAID 5 ou 6 incluído discos de reserva, xa sexa parados (StandBy Spare) ou conectados e preparados (Hot Spare). O beneficio é unha maior velocidade de reconstrucción en caso de fallo no caso deos discos Hot Spare, e sobre todo maior facilidade de administración.
É moi común o uso de modos anidados, que empregan un modo RAID sobre outro. Configuracións típicas son:
- RAID 0+1 - Son dous conxuntos en RAID 0 sobre os que se aplica un RAID 1. Con esto se consigue agregar ao RAID 0 protección contra os fallos.
- RAID 10 (1+0) - Son dous conxuntos en RAID 1 sobre os que se aplica un RAID 0. Con esto se aumenta a velocidade no acceso na escritura e lectura.
De xeito similar podemos falar de RAID 30 (3+0), RAID 100 (10+0), RAID 50 (5+0).
Existen dúas aproximacións a hora de implementar un sistema RAID. Recurrir a controladoras de disco con soporte RAID, ou o uso do propio sistema operativo para implantar o RAID, cada modo ten as súas ventaxas e inconvintes.
O RAID por Hardware ten as seguintes ventaxas:
- Facilidade de instalación.
- Facilidade a hora de reemplazar un disco. As controladoras RAID facilitan o cambio de discos en quente.
- Posiblemente maior rendimento. As controladoras RAID descargan á CPU de todo o procesamento (como o cálculo dos datos de paridade) acelerando o rendimento sobre todo nas tarxetas de gama alta. Hoxe en día, coa gran potencia das CPU esta diferencia é mínima e incluso si non temos unha controladora RAID de alta gama, o rendimento ofrecido polo RAID Software é superior ao hardware.
Os inconvintes son os seguintes:
- Sistemas propietarios e incompatibles. Cada fabricante ten o seu propio sistema de xestión e monitorización, e ademáis a rotura dunha controladora pode supoñer a perda completa de toda a información si non atopamos un modelo compatible.
- Maior custo. As controladoras de gama baixa ofrencen pobres rendimentos, e as de gama alta teñen un precio alto.
- Pouca Flexibilidade. As controladoras RAID ofrecen soporte a uns poucos modos RAID, e se realiza por discos completos.
O RAID por Software ten as seguintes ventaxas:
- Independencia do Hardware. Non se depende das controladoras, o fallo dunha controladora non supón ningún problema sobre o posterior acceso a información.
- Ferramentas de Monitorización estándar. Os sistemas de monitorización son homoxéneos.
- Bo rendimento. A gran potencia das CPU actuais proporcionan un gran rendimento, en ocasións moi superior a algunhas solucións hardware.
- Menor custo.
- Gran Flexibilidade. O RAID software soporta moitos modos, e é posible o RAID por particións.
Os inconvintes son os seguintes:
- Maior dificultade de instalación e administración. É necesario aprender a utilizar os comandos do sistema de xestión de RAID. A sustitución dun disco do RAID require un traballo previo de preparación.
- Posible menor rendimento. Si non se dispón de potencia de CPU o rendimento é inferior ás solucións hardware con controladoras de gama alta.
- Uso da CPU. É necesario ocupar ciclos de CPU nos cálculos necesarios para o RAID.
Almacenamento en Volumes
O emprego de de volumes proporciona métodos de reserva de espacio nos dispositivos de almacenamento dun xeito máis flexible que os esquemas de particións. Este tipo de sistemas permiten dividir, ou combinar particións en áreas de almacenamento maiores que os administradores poden dividir, redimensionar, ou mover sin interrumpir o uso do sistema. Si un servidor precisa máis espazo de disco, bastará con engadirlle un novo disco físico, agregalo ao volume indicaco e asignar o espazo requerido , sen necesidade de deter o sistema nin alterar a división de almacenamento empregada (non aparecerán novas unidades nin serán necesarios novos puntos de montaxe).
Outra das posibilidades ofrecidas é a realización de “snapshots” ou "instantáneas", que se poden utilizar para a realización de copias de seguridade en quente de información que está continuamente en uso, como poden ser as bases de datos, ou para realizar un conxunto de operacións que podan logo desfacerse con facilidade.
Existen varias implementacións de sistemas de volumes, sendo as máis comúns LVM (Logical Volume Manager) baixo Linux e Logical Disk Manager nos sistemas posteriores a Windows 2000.
- Linux: LVM (Logical Volume Manager)
- Neste sistema de almacenamento se crean Grupos de Volumes (GV) agrupando un ou varios dispositivos de bloques (normalmente particións de disco, ou discos completos) que reciben o nome de Volumes Físicos. É posible engadir dinámicamente novos volumes físicos a un grupo de volumes, ou retiralos si non están en uso.
- Os Grupos de Volumes se dividen en Volumes Lóxicos (serían o equivalente ás particións) que serán formateados e montados para o seu uso.
- Os Volumes Físicos poden engadirse en varios modos, como pode ser o stripping equivalente ao RAID 0, ou mirroring, equivalente a RAID 1. As últimas versións de LVM para Linux permiten sustituir completamente a capa de RAID por LVM.
- Sempre que o Grupo de Volumes teña espacio libre será posible realizar unha instantánea (snapshot) de calqueira volume lóxico. O snapshot únicamente garda os cambios que se realicen sobre o sistema, de xeito que permanecerá sen cambios aínda que o volume orixinal continúe en uso.
- Windows: Logical Disk Manager.
- Este sistema denominado discos dinámicos está presente a partir dos sistemas Windows 2000, e foi desenvolto por Veritas. O espazo de almacenamento está nunha única partición que ocupa todo o disco. Esta partición pode combinarse con outras para crear un espacio maior e dividila posteriormente en volumes lóxicos chamados volumes dinámicos. Os discos normais poden convertirse en discos dinámicos fácilmente, pero o paso contrario (de disco dinámico a disco normal) non é posible sin destruir a información almacenada.
Clústers de Alta Dispoñibilidade
É posible que por diversas circunstancias non previstas un equipamento deixe de prestar o servizo. Nestas circunstancias é imprescindible evitar o fallo no procesamento das peticións que impediría a un sistema de alta dispoñibilidade acadar o nivel de servicio acordado. A solución típica para este problema é a configuración de servidores de reserva que comezarán a dar servizo no momento en que se produza unha caida do servidor principal. Este tipo de sistemas denomínanse clúster de alta dispoñibilidade. a Os clusters de alta dispoñibilidade necesitan monitorizar continuamente o correcto funcionamento do servidor principal, e en caso de detectar unha caída do servicio, reconfigurar os sistemas de modo que o servidor de reserva tome o seu lugar. A monitorización pode realizarse con granularidade de servidor (se detecta si o servidor está en funcionamento ou non) ou de servizo (se monitoriza a dispoñibilidade dos servicios a configurar en HA).
Ademáis da monitorización dos servizos, normalmente é necesario un sistema que se encargue de organizar a parada e arranque de servizos nos nodos do cluster e decidir sobre os nodos que reemplazarán ao nodo que fallou.
Outro tema importante é asegurarse de que non se produzan "falsas caidas" que provoquen un funcionamento anómalo do cluster provocado por varios nodos ofrecendo o mesmo servizo. Esto se acada mediante dispositivos STONITH (Shoot The Other In The Head) que se aseguran que o nodo caído non vai a continuar ofrecendo o servizo.
Algúns sistemas para implantar clustering HA son:
- Heartbeat - E un monitor con unha capacidade limitada a hora de reconfigurar os servicios. É util para sistemas simples en que únicamente dispoñemos de 2 nodos monitorizados con granularidade de servidor.
- Heartbeat+Pacemaker - Se combina Heartbeat con Pacemaker, que nos ofrece granuralidade de servizo e xestión de múltiples nodos no clúster.
- Corosync+Pacemaker - O monitor a utilizar e Corosync, que ofrece funcionalidades similares a Heartbeat pero non permite a xestión de clústeres sen Pacemaker.
- CMAN - é un sistema parte da RedHat Cluster Suite para crear clusters de alta dispoñibilidade. Principalmente actúa como xestor de quorum, que é un sistema de puntuación para decidir qué nodo do cluster se fará cargo do servizo. Se encargará de iniciar e parar todos os compoñentes necesarios para a operación do cluster facemdo unha función similar a pacemaker.
Un dos problemas existentes cando un servidor ten que reemplazar a outro e continuar co servizo no mesmo punto é a xestión da información. Todos os nodos do cluster ofrecendo o servizo necesitan ter acceso aos mesmos datos. Existen dúas formas de acadar este obxectivo:
- Almacenamento Remoto: Os servidores almacenan a información en un sistema de almacenamento compartido como un SAN ou NAS.
- DRBD (Distributed Replicated Block Device): É un sistema no que se pode realizar un RAID-1 entre dispositivos de bloques conectados en rede. Deste xeito, dous servidores poden obter unha copia exacta dos mesmos datos en todo momento.