Uso de la replicación de bloque síncrona remota en Oracle Cloud Infrastructure
Proporcione tolerancia a fallos de volúmenes en bloque mediante la replicación de bloques síncrona remota.
Los desafíos típicos para muchas empresas incluyen: aplicaciones que se ejecutan sobre una base de datos, aplicaciones que acceden a dispositivos de bloques subyacentes y un requisito de negocio para cero retrasos en los servicios.
Por ejemplo, las empresas de procesamiento de pagos. Como un retraso en el procesamiento de pagos afecta negativamente a la reputación y la marca a los ojos de sus clientes, necesitan contar con tecnología de alta disponibilidad para proporcionar una verdadera tolerancia a fallos (es decir, cero interrupciones del servicio en caso de un fallo de un solo componente).
Arquitectura
Esta arquitectura implanta un dispositivo de bloques de alta disponibilidad en Oracle Cloud Infrastructure (OCI), totalmente tolerante a fallos en el nivel de aplicación de negocio. Utilice esta arquitectura para aplicaciones sensibles al rendimiento que requieren continuidad al mismo tiempo.
Esta arquitectura proporcionará una única entidad, un dispositivo de bloques iSCSI a los usuarios. Este dispositivo estará siempre disponible, independientemente de los fallos de un solo componente. Cualquier otro componente de la arquitectura estará oculto para los usuarios. La arquitectura está totalmente automatizada en caso de fallo o switchover. El único efecto que los usuarios notarán en caso de fallo o switchover será la degradación del rendimiento del dispositivo iSCSI en alrededor del 50 % durante uno o dos segundos.
La implantación de un solo dispositivo de bloques siempre disponible requiere lo siguiente.
- Tres instancias informáticas, máquinas virtuales o hardware dedicado (BM). Esto último puede ser preferible, ya que tienen un rendimiento estable.
- Dos VCN: una pública, una privada.
- Dos volúmenes en bloque del dispositivo de destino siempre disponible.
- (Recomendado) Tenga los volúmenes en bloque de al menos 10 VPU. Puede que desee considerar un nivel aún mayor de IOPS, en función de la agresividad del rendimiento de E/S y la distancia entre los hosts reflejados (y los volúmenes en bloque).
Por lo tanto, el costo de implementar un dispositivo de bloques siempre disponible es tres veces el costo de la instancia informática más dos veces el costo del propio dispositivo.
El siguiente diagrama ilustra esta arquitectura de referencia.
remoto-síncrono-bloque-replicación-diagrama-oracle.zip
La arquitectura tiene los siguientes componentes:
- Dispositivo de bloque replicado distribuido
Distributed Replicated Block Device (DRBD) es un controlador de núcleo de Linux que mantiene la conexión de red entre dos dispositivos de bloques en instancias remotas de Linux y replica las operaciones de E/S de la instancia de origen a la instancia de destino.
- Marcapasos
Pacemaker es un gestor de recursos de cluster de alta disponibilidad de código abierto, comúnmente utilizado en entornos Linux. Garantiza que las aplicaciones, los servicios o los recursos se ejecuten continuamente con un tiempo de inactividad mínimo mediante la detección de fallos y el reinicio o la reubicación automáticos de servicios en otros nodos de un cluster.
- Corosíncrona
Corosync es un software de código abierto que extiende el marcapasos con semántica de restauración en el caso del cerebro dividido.
- Iniciador y destino iSCSI
iSCSI es un componente de software de cliente y servidor que proporciona un dispositivo SCSI a través de una red.
Recomendaciones
- VCN
Al crear una VCN, determine el número de bloques CIDR necesarios y el tamaño de cada bloque en función del número de recursos que planea asociar a las subredes de la VCN. Utilice bloques CIDR que estén dentro del espacio de direcciones IP privadas estándar.
Seleccione bloques de CIDR que no se solapen con ninguna otra red (en Oracle Cloud Infrastructure, su centro de datos local u otro proveedor en la nube) a la que desee configurar conexiones privadas.
Después de crear una VCN, puede cambiar, agregar y eliminar sus bloques CIDR.
Al diseñar las subredes, tenga en cuenta el flujo de tráfico y los requisitos de seguridad. Asocie todos los recursos de un nivel o rol específico a la misma subred, que puede servir como límite de seguridad.
- Cloud Guard
Clone y personalice las recetas por defecto proporcionadas por Oracle para crear recetas personalizadas de detector y responsable de respuesta. Estas recetas permiten especificar qué tipo de violaciones de seguridad generan una advertencia y qué acciones se pueden realizar en ellas. Por ejemplo, puede que desee detectar cubos de Object Storage que tengan la visibilidad definida en pública.
Aplique Cloud Guard en el nivel de arrendamiento para abarcar el ámbito más amplio y reducir la carga administrativa de mantener varias configuraciones.
También puede utilizar la función de lista gestionada para aplicar determinadas configuraciones a los detectores.
- Security Zones
Para los recursos que requieren la máxima seguridad, Oracle recomienda utilizar zonas de seguridad. Una zona de seguridad es un compartimento asociado a una receta de políticas de seguridad definida por Oracle que se basa en las mejores prácticas. Por ejemplo, no se puede acceder a los recursos de una zona de seguridad desde la Internet pública y se deben cifrar mediante claves gestionadas por el cliente. Al crear y actualizar recursos en una zona de seguridad, Oracle Cloud Infrastructure valida las operaciones con respecto a las políticas de la receta de zona de seguridad y deniega las operaciones que violan cualquiera de las políticas.
- Grupos de seguridad de red (NSG)
Puede utilizar NSG para definir un juego de reglas de entrada y salida que se aplican a VNIC específicas. Recomendamos utilizar NSG en lugar de listas de seguridad, ya que los NSG permiten separar la arquitectura de subred de la VCN de los requisitos de seguridad de la aplicación.
- Ancho de banda de equilibrador de carga
Al crear el equilibrador de carga, puede seleccionar una unidad predefinida que proporcione un ancho de banda fijo o especificar una unidad personalizada (flexible) en la que defina un rango de ancho de banda y permita que el servicio amplíe el ancho de banda automáticamente en función de los patrones de tráfico. Con cualquiera de los enfoques, puede cambiar la unidad en cualquier momento después de crear el equilibrador de carga.
Consideraciones
Tenga en cuenta lo siguiente al desplegar esta arquitectura de referencia.
- Rendimiento
Debe planificar dos veces N de IOPS nominales en su dispositivo siempre disponible para proporcionar N IOPS a sus usuarios. Esto se debe al hecho de que la mitad del rendimiento se dedica a la duplicación en tiempo real.
- Seguridad
Recomendamos encarecidamente aislar los detalles de implantación dividiendo la solución en redes públicas y privadas.
- Disponibilidad
Recomendamos implementar dispositivos siempre disponibles, ya que iSCSI para esta tecnología no tiene en cuenta el sistema operativo, por lo que los usuarios pueden disfrutar de una verdadera tolerancia a fallos tanto si ejecutan Linux como Windows en sus máquinas.
Todos los componentes de software de la solución están disponibles públicamente como productos de código abierto. En particular, el controlador DRBD es un componente integral del núcleo de Linux vainilla y está disponible en cualquier distribución de Linux.