Alta disponibilidad (AD) se refiere al objetivo de mantener un sistema o aplicación operativo y disponible para los usuarios un porcentaje muy alto del tiempo, minimizando el tiempo de inactividad planificado y no planificado.
Es posible que hayáis notado que, para configurar un mirror en InterSystems IRIS for Health™ y HealthShare® Health Connect, hay un requisito especial. En este artículo, quiero guiaros paso a paso por el proceso.
Esto supone que ya habéis configurado el segundo miembro de conmutación por error y habéis confirmado un estado exitoso de dicho miembro en el monitor del mirror:
Paso 1: Activad el usuario HS_Services (en el servidor de respaldo y en el principal)..png)
Si eres administrador de sistemas y/o de base de datos y trabajas con InterSystems IRIS, este curso te puede ayudar a mantener tus instancias bien configuradas y con rendimiento óptimo.
Con el curso de Fundamentos de Administración aprenderás la información esencial y necesaria para configurar la plataforma de datos de InterSystems, realizar tareas de mantenimiento como copias de seguridad, monitorización, resolución de problemas y control de acceso de usuario.
En nuestro portal de formaciónpuedes consultar todos los cursos oficiales programados.
Todos los pods reciben una asignación de Calidad de Servicio (QoS). Existen tres niveles de prioridad dentro de un nodo:
Es una forma de indicar al kubelet cuáles son vuestras prioridades en un nodo si es necesario recuperar recursos. Este fantástico GIF de Anvesh Muppeda lo explica.
Entre las diversas soluciones que desarrollamos en Innovatium, un desafío habitual es la necesidad de acceder al tamaño de las bases de datos. Entonces me di cuenta de que eso no es algo tan trivial en IRIS. Ese tipo de información es importante para mantener un control del flujo de datos y del coste en gigabytes de un sistema para implementar. Sin embargo, lo que realmente me llamó la atención fue la necesidad de eso para algo muy importante: la migración a la nube. Al final, ¿quién no quiere migrar sus sistemas a la nube hoy en día?
Una necesidad habitual en nuestros clientes es la configuración tanto de HealthShare HealthConnect como de IRIS en modo de alta disponibilidad.
Es común en otros motores de integración del mercado que se promocionen con configuraciones de "alta disponibilidad", pero realmente no suele ser del todo cierto. Por lo general dichas soluciones trabajan con bases de datos externas y por lo tanto, si estas no están a su vez configuradas en alta disponibilidad, al producirse una caída de la base de datos o la pérdida de conexión a la misma toda la herramienta de integración queda inutilizable.
En el caso de las soluciones de InterSystems este problema no existe, al ser la base de datos parte y nucleo de las propias herramientas. ¿Y cómo ha solucionado InterSystems el problema de la alta disponibilidad? ¿Con abstrusas configuraciones que podrían arrastrarnos a una espiral de enajenamiento y locura? ¡NO! Desde InterSystems hemos escuchado y atendido vuestras quejas (como siempre intentamos hacer ;) ) y hemos puesto a disposición de todos nuestros usuarios y desarrolladores la función de mirroring.
Hola!
Aquí les dejo un video que hice para mostrar cómo se configura la alta disponibilidad (mirroring) en IRIS en un ambiente docker, el video esta completamente en español y los archivos necesarios estarán en mi Github.
El video en YouTube en https://youtu.be/rBdiTxavWmU
https://github.com/I-am-seven/iris-mirroring-video
Espero les sea de Utilidad!
Joel
¡Hola Comunidad!
Hemos grabado el webinar que hicimos ayer y lo hemos subido al canal de YouTube de la Comunidad de Desarrolladores en español. Si os perdisteis el webinar o lo queréis volver a ver con más detalle, ya está disponible la grabación!
Alberto Fuentes mostró cómo desplegar arquitecturas de InterSystems IRIS con Alta Disponibilidad utilizando Kubernetes y el IKO (InterSystems Kubernetes Operator), utilizó servicios de AWS (Amazon Web Services) para realizar ejemplos de despliegue, comentó distintas arquitecturas de alta disponibilidad que se pueden montar fácilmente.... ¡y muchas cosas más! Por eso, si utilizáis Kubernetes... ¡no os perdáis el vídeo!
⏯ Despliegues en Kubernetes con Alta Disponibilidad
<iframe width="560" height="315" src="https://www.youtube.com/embed/PRjE57B5Emw" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
Además de este webinar, en el canal de YouTube de la Comunidad podéis ver otro webinar sobre Kubernetes, que es un buen punto de partida para conocer esta plataforma open source:
⏯ Webinar 7: Sacando el máximo rendimiento a Kubernetes
Por cierto, en las listas de reproducción del canal de YouTube de la Comunidad de Desarrolladores en español podéis ver todos los webinars que hemos realizado (¡ya llevamos diecinueve!), varios tutoriales, trucos, demos...
¡Echadle un ojo y dadle al play! ▶️
¡Hola desarrolladores!
Os invitamos a un nuevo webinar en español: "Despliegues en Kubernetes con Alta Disponibilidad", el jueves 20 de octubre, a las 4:00 PM (CEST).
El webinar está dirigido a desarrolladores y técnicos DevOps que quieran aprender a automatizar de forma sencilla despliegues de tecnología InterSystems utilizando Kubernetes.
Durante el webinar:
En este artículo, crearemos una configuración de IRIS con alta disponibilidad utilizando implementaciones en Kubernetes con almacenamiento persistente distribuido en vez del "tradicional" par de mirror de IRIS. Esta implementación sería capaz de tolerar fallos relacionados con la infraestructura, por ejemplo, fallos en los nodos, en el almacenamiento y en la Zona de Disponibilidad. El enfoque descrito reduce en gran medida la complejidad de la implementación, a costa de un Tiempo Objetivo de Recuperación (RTO, Recovery Time Objective) ligeramente mayor.
Todo el código fuente del artículo está disponible en: https://github.com/antonum/ha-iris-k8s
En el artículo anterior, comentamos cómo configurar IRIS en el clúster k8s con alta disponibilidad, basado en el almacenamiento distribuido, en vez del mirroring tradicional. Como ejemplo, ese artículo utilizaba el clúster Azure AKS. En esta ocasión, seguiremos explorando las configuraciones de alta disponibilidad en los k8s. Esta vez, basado en Amazon EKS (servicio administrado para ejecutar Kubernetes en AWS) e incluiría una opción para hacer copias de seguridad y restauraciones de la base de datos, basado en Kubernetes Snapshot.
Vamos a lo más importante. Primero: necesitas una cuenta de AWS, y las herramientas AWS CLI,kubectl y eksctl instaladas. Para crear el nuevo clúster, ejecuta el siguiente comando:
eksctl create cluster \ --name my-cluster \ --node-type m5.2xlarge \ --nodes 3 \ --node-volume-size 500 \ --region us-east-1
Este comando tarda unos 15 minutos, implementa el clúster EKS y lo convierte en un clúster predeterminado para tu herramienta kubectl. Puedes verificar la implementación ejecutando:
kubectl get nodes NAME STATUS ROLES AGE VERSION ip-192-168-19-7.ca-central-1.compute.internal Ready <none> 18d v1.18.9-eks-d1db3c ip-192-168-37-96.ca-central-1.compute.internal Ready <none> 18d v1.18.9-eks-d1db3c ip-192-168-76-18.ca-central-1.compute.internal Ready <none> 18d v1.18.9-eks-d1db3c
El siguiente paso es instalar el motor de almacenamiento distribuido Longhorn.
kubectl create namespace longhorn-system kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.1.0/deploy/iscsi/longhorn-iscsi-installation.yaml --namespace longhorn-system kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml --namespace longhorn-system
Y, por último, el propio IRIS:
kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr.yaml
En este momento, tendrás un clúster EKS completamente funcional con el almacenamiento distribuido de Longhorn y la implementación de IRIS instaladas. Puedes volver al artículo anterior e intentar hacer todo tipo de daño en el clúster y la implementación de IRIS, solo para ver cómo el sistema se repara a sí mismo. Echa un vistazo a la sección "Simulación del error".
IRIS EKS y Longhorn son compatibles con la arquitectura ARM, por lo que podemos implementar la misma configuración utilizando instancias de AWS Graviton2, basadas en la arquitectura ARM.
Todo lo que necesitas es cambiar el tipo de instancia para los nodos EKS a la familia "m6g" y la imagen IRIS a la basada en ARM.
eksctl create cluster \
--name my-cluster-arm \
--node-type m6g.2xlarge \
--nodes 3 \
--node-volume-size 500 \
--region us-east-1
tldr.yaml
containers: #- image: store/intersystems/iris-community:2020.4.0.524.0 - image: store/intersystems/irishealth-community-arm64:2020.4.0.524.0 name: iris
O simplemente utiliza:
kubectl apply -f https://github.com/antonum/ha-iris-k8s/raw/main/tldr-iris4h-arm.yaml
¡Eso es todo! Ya tienes el clúster IRIS Kubernetes, ejecutándose en la plataforma ARM.
Una parte de la arquitectura para nivel de producción que se suele pasar por alto es la capacidad de crear copias de seguridad de la base de datos y que las restaure y/o clone rápidamente cuando sea necesario.
En Kubernetes, la manera más habitual de hacerlo es utilizando Persistent Volumen Snapshots (Snapshots de volumen persistente).
En primer lugar, debes instalar todos los componentes de k8s requeridos:
#Install CSI Snapshotter and CRDs kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotcontents.yaml kubectl apply -n kube-system -f https://github.com/kubernetes-csi/external-snapshotter/raw/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshotclasses.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/client/config/crd/snapshot.storage.k8s.io_volumesnapshots.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/setup-snapshot-controller.yaml kubectl apply -n kube-system -f https://raw.githubusercontent.com/kubernetes-csi/external-snapshotter/master/deploy/kubernetes/snapshot-controller/rbac-snapshot-controller.yaml
A continuación, configura las credenciales del bucket S3 para Longhorn (consulta estas instrucciones):
#Longhorn backup target s3 bucket and credentials longhorn would use to access that bucket #See https://longhorn.io/docs/1.1.0/snapshots-and-backups/backup-and-restore/set-backup-target/ for manual setup instructions longhorn_s3_bucket=longhorn-backup-123xx #bucket name should be globally unique, unless you want to reuse existing backups and credentials longhorn_s3_region=us-east-1 longhorn_aws_key=AKIAVHCUNTEXAMPLE longhorn_aws_secret=g2q2+5DVXk5p3AHIB5m/Tk6U6dXrEXAMPLE
El siguiente comando tomará las variables de entorno del paso anterior y las utilizará para configurar la copia de seguridad de Longhorn
#configure Longhorn backup target and credentials cat <<EOF | kubectl apply -f - apiVersion: longhorn.io/v1beta1 kind: Setting metadata: name: backup-target namespace: longhorn-system value: "s3://$longhorn_s3_bucket@$longhorn_s3_region/" # backup target here --- apiVersion: v1 kind: Secret metadata: name: "aws-secret" namespace: "longhorn-system" labels: data: # echo -n '<secret>' | base64 AWS_ACCESS_KEY_ID: $(echo -n $longhorn_aws_key | base64) AWS_SECRET_ACCESS_KEY: $(echo -n $longhorn_aws_secret | base64) --- apiVersion: longhorn.io/v1beta1 kind: Setting metadata: name: backup-target-credential-secret namespace: longhorn-system value: "aws-secret" # backup secret name here EOF
Puede parecer mucho, pero esencialmente le indica a Longhorn que utilice un bucket S3 específico con las credenciales precisas para almacenar el contenido de las copias de seguridad.
¡Eso es todo! Si ahora vas a la interfaz de usuario de Longhorn, podrás crear copias de seguridad, restaurarlas, etc.
Un recordatorio rápido sobre cómo conectarse a la interfaz de usuario de Longhorn:
kubectl get pods -n longhorn-system # note the full pod name for 'longhorn-ui-...' pod kubectl port-forward longhorn-ui-df95bdf85-469sz 9000:8000 -n longhorn-system
Esto reenviaría el tráfico desde la interfaz de usuario de Longhorn a tu http://localhost:9000
Hacer copias de seguridad y restauraciones a través de la interfaz de usuario de Longhorn podría ser un primer paso suficientemente bueno, pero vamos a ir un paso más allá y realizar copias de seguridad y restauraciones programáticamente, utilizando APIs de Snapshots k8s.
En primer lugar, el propio snapshot. iris-volume-snapshot.yaml
apiVersion: snapshot.storage.k8s.io/v1beta1
kind: VolumeSnapshot
metadata:
name: iris-longhorn-snapshot
spec:
volumeSnapshotClassName: longhorn
source:
persistentVolumeClaimName: iris-pvcEste snapshot de volumen se refiere al volumen de la fuente "iris-pvc" que usamos para nuestra implementación de IRIS. Así que con solo aplicar esto, el proceso para crear una copia de seguridad se iniciaría inmediatamente .
Es una buena idea ejecutar el Freeze/Thaw de IRIS Write Daemon antes o después del snapshot.
#Freeze Write Daemon echo "Freezing IRIS Write Daemon" kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalFreeze()" status=$? if [[ $status -eq 5 ]]; then echo "IRIS WD IS FROZEN, Performing backup" kubectl apply -f backup/iris-volume-snapshot.yaml -n $namespace elif [[ $status -eq 3 ]]; then echo "IRIS WD FREEZE FAILED" fi #Thaw Write Daemon kubectl exec -it -n $namespace $pod_name -- iris session iris -U%SYS "##Class(Backup.General).ExternalThaw()"
El proceso de restauración es bastante sencillo. Esencialmente se crea un nuevo PVC y se especifican los snapshots como la fuente.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: iris-pvc-restored
spec:
storageClassName: longhorn
dataSource:
name: iris-longhorn-snapshot
kind: VolumeSnapshot
apiGroup: snapshot.storage.k8s.io
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 10GiA continuación, solo hay que crear una nueva implementación, basada en este PVC. Comprueba este script de prueba en un repositorio de github que podría realizarse con la siguiente secuencia:
En este momento tendrá dos implementaciones idénticas de IRIS, una de las cuales es un clon hecho por medio de una copia de seguridad de la otra.
¡Espero que os resulte útil!
Estimados,
Junto con saludarles consulto han implementado InterSystems IRIS Mirroring para IRIS 2019.2 en AWS?. Necesito tener dos AZ, subredes privadas, y lograr configurar los nodos primario y secundario de IRIS base de datos. Los gateway que están en API Management (IAM) deberán enviar peticiones a una IP que esté delante de los nodos de base de datos de IRIS. Agradeceré compartir un esquema de arquitectura
Para aquellos a los que, en un momento dado, necesitan probar cómo va eso del ECP para escalabilidad horizontal (cómputo y/o concurrencia de usuarios y procesos), pero les da pereza o no tienen tiempo de montar el entorno, configurar los nodos, etc..., acabo de publicar en Open Exchange la aplicación/ejemplo OPNEx-ECP Deployment .
¡Hola desarrolladores!
Os traemos el quinto episodio de Data Points, el podcast de InterSystems en inglés. En esta ocasión, charlamos con Bob Binstock sobre bases de datos en mirroring para alta disponibilidad en productos InterSystems. La mayor parte de la conversación comenta este proceso en InterSystems IRIS, con alguna mención sobre las diferencias con HealthShare. ¡Dadle al play!
++ Update: August 1, 2018
El uso de la dirección IP virtual (VIP) de InterSystems incorporada en Mirroring de la base de datos de Caché tiene ciertas limitaciones. En particular, solo puede utilizarse cuando los miembros Mirror se encuentran en la misma subred. Cuando se utilizan varios centros de datos, las subredes normalmente no se “extienden” más allá del centro de datos físico debido a la complejidad añadida de la red (puede obtener más información aquí). Por las mismas razones, la IP virtual con frecuencia no puede utilizarse cuando la base de datos se aloja en la nube.