0 Seguidores · 19 Publicaciones

Amazon Web Services (AWS) es una plataforma de herramientas y servicios web, como almacenamiento, bases de datos, herramientas para desarrolladores, sistemas de Business Intelligence y otros servicios y funcionalidades, para ayudar a las empresas a ser más eficientes.

Aprende más

Artículo Derek Gervais · sep 15, 2025 3m read

¡Hola a todos! Tras incorporarme recientemente a InterSystems, me di cuenta de que, a pesar de tener una Community Edition totalmente gratuita y genial, no está muy claro cómo conseguirla. Decidí escribir una guía destacando todas las diferentes formas en que podéis acceder a la Community Edition de InterSystems IRIS:

Conseguir InterSystems IRIS Community Edition como contenedor

Trabajar con una instancia en contenedor de la Community Edition es el enfoque recomendado para quienes son nuevos en el desarrollo con InterSystems IRIS, y en mi opinión es el más sencillo. InterSystems IRIS Community Edition se puede encontrar en DockerHub; si tenéis una cuenta SSO de InterSystems, también podéis encontrarla en el InterSystems Container Registry.

En cualquiera de los casos, descargaréis la imagen que necesitéis usando la CLI de Docker:

docker pull intersystems/iris-community:latest-em
// or
docker pull containers.intersystems.com/intersystems/iris-community:latest-em

A continuación, tendréis que iniciar el contenedor: para poder interactuar con IRIS desde fuera del contenedor (por ejemplo, para usar el portal de administración) necesitaréis publicar algunos puertos. El siguiente comando ejecutará el contenedor de IRIS Community Edition con los puertos del superserver y del servidor web publicados; tened en cuenta que no podéis tener nada más en ejecución que dependa de los puertos 1972 o 52773.

docker run --name iris -d --publish 1972:1972 --publish 52773:52773 intersystems/iris-community:latest-em
0
0 27
Anuncio Sergio Farago · jul 18, 2025

Hola, comunidad:

La semana pasada, el equipo de InterSystems celebró nuestro encuentro mensual de desarrolladores en un nuevo lugar por primera vez. En la oficina de AWS en Boston, en el Seaport, más de 71 asistentes se reunieron para charlar, hacer networking y escuchar las charlas de dos ponentes increíbles. El evento fue todo un éxito; tuvimos el lugar lleno, muchísima participación y preguntas, ¡y asistentes haciendo cola para hablar con nuestros ponentes después!

Photo of a large audience watching the speaker Jayesh Gupta present his topic
Jayesh presenta sobre marcos de prueba para Agentic Systems ante un auditorio lleno.

0
0 31
Artículo Mario Martín · mayo 31, 2024 3m read

Buenos días a todos:

Trabajo en el sector bancario en el área de seguridad. Indagando sobre nuevas tecnologías y posibilidades, he planteado si InterSystems IRIS podría aportar algún valor en el tratamiento de datos. La respuesta es que sí; IRIS permite la centralización de datos y el análisis en tiempo real de los mismos. Además, podríamos beneficiarnos de la interoperabilidad de su tecnología. Si bien es cierto que InterSystems está muy avanzado en el ámbito sanitario, estoy convencido de que sus beneficios podrían aplicarse a otras áreas como la banca.

0
0 129
Anuncio Esther Sanchez · oct 21, 2022

¡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! ▶️

0
1 165
Artículo Alberto Fuentes · ago 4, 2022 11m read

Al igual que los servidores hardware, los servidores virtuales en nubes públicas y privadas pueden generar cuellos de botella en los recursos, según aumentan las cargas de trabajo. Si utilizas y administras instancias de InterSystems IRIS implementadas en nubes públicas o privadas, es posible que te hayas encontrado la situación en la que para solucionar problemas de rendimiento o de otro tipo se requiere aumentar la capacidad del servidor de una instancia (es decir, escalar verticalmente).

Un motivo frecuente es la memoria insuficiente. Como se describe en la Administración de la memoria y escalamiento de InterSystems IRIS que se encuentra en la Guía de escalabilidad, proporcionar suficiente memoria para todas las estructuras que se ejecutan en el servidor de una instancia de InterSystems IRIS en todas las circunstancias normales de funcionamiento, es un factor crítico tanto para el rendimiento como para la disponibilidad. En un escenario común, conforme aumenta la carga de trabajo en una instancia de InterSystems IRIS, su conjunto de trabajo se vuelve demasiado grande para ser contenido por la memoria caché reservada para las estructuras de la base de datos. Esto lo obliga a que algunas consultas tengan que ir a disco, lo que aumenta significativamente el número de lecturas requeridas del disco y crea un problema importante de rendimiento. Aumentar el tamaño de esta memoria caché resuelve ese problema, pero si al hacerlo no queda suficiente memoria para otros propósitos, también habrá que aumentar la memoria física total del servidor para evitar que el cuello de botella se desplace hacia otra parte del sistema.

Afortunadamente, escalar un servidor virtual generalmente es mucho más sencillo que escalar uno hardware. En esta publicación se analizan las dos etapas del proceso:

  • Cómo escalar los recursos del servidor virtual 

Se puede cambiar la especificación de recursos de un servidor virtual en AWS, GCP y Azure, utilizando la línea de comandos, la API o el portal de la plataforma. VMWare vSphere permite modificar fácilmente varios parámetros de los recursos para una máquina virtual mediante su interfaz de cliente vSphere.

  • Cómo reconfigurar InterSystems IRIS para aprovechar los recursos escalados

Hay varias maneras de reconfigurar InterSystems IRIS para aprovechar los recursos del servidor escalado. Este documento describe el uso de la función Combinar la configuración, que combina nuevos valores de los parámetros, especificados en un archivo combinado, en el CPF de una instancia. Combinar la configuración es un método sencillo y eficaz porque permite ocuparse únicamente de la configuración que se quiere modificar, hacer varios cambios en la configuración de una instancia con una sola operación y realizar fácilmente el mismo conjunto de cambios en varias instancias.

Los procedimientos descritos aquí son manuales, pero en producción muy probablemente serían automatizados, por ejemplo usando un script que aplicaría un archivo combinado específico en una ubicación accesible para una lista de instancias.

Cómo escalar los recursos del host virtual

Las plataformas publicas en la nube ofrecen una variedad de plantillas de recursos para elegir, que especifican el CPU, la memoria, las interfaces de red y otros recursos para hosts virtuales (el almacenamiento se suministra y se dimensiona por separado). Para cambiar el tamaño de un servidor, hay que cambiar la plantilla seleccionada cuando se creó el host a una permita especificar los recursos que necesitas aumentar. En Amazon Web Services, la plantilla de recursos se denomina un tipo de instancia, por ejemplo, el tipo de instancia t3.large especifica 2 CPUs y 8 GB de memoria. En la plataforma Google Cloud es un tipo de máquina, como la e2-standard-2 (que también incluye 2 CPUs y 8 GB), y en Microsoft Azure es un tamaño (el Standard_B2ms requiere igualmente 2 CPUs y 8 GB). Al redefinir el tipo de instancia, tipo de máquina o tamaño del servidor de una nube pública existente, se pueden escalar las especificaciones de sus recursos. En una nube privada de VMware vSphere, se puede utilizar la interfaz de cliente vSphere en la consola de administración vCenter Server para modificar directamente una o más configuraciones de los recursos individuales de una máquina virtual existente. (También se pueden escalar simultáneamente grupos de servidores en cada plataforma).

En las siguientes secciones se ofrecen breves ejemplos sobre cómo redimensionar servidores virtuales individuales en distintas plataformas, con enlaces a la documentación para todos los métodos disponibles. Ten en cuenta que estos métodos (API, interfaces de línea de comandos e interfaces del portal) se proporcionan y mantienen gracias a los proveedores en la nube, y los ejemplos que aquí se incluyen son con propósitos informativos, para ilustrar con qué facilidad se puede adaptar InterSystems IRIS para aprovechar el aumento en los recursos. 

AWS

Para modificar el tipo de instancia de un servidor AWS (denominada instance, no debe confundirse con una instancia de InterSystems IRIS) se puede utilizar el comando CLI modify-instance-attribute, como se muestra en el siguiente ejemplo:

$ aws ec2 describe-instances --instance-ids i-01519f663af48a55e
{
   "Instances": [
        {
            "AmiLaunchIndex": 0,
            "ImageId": "ami-0abcdef1234567890,
            "InstanceId": "i-1234567890abcdef0,
            "InstanceType": "m5n.large",
            ...
$ aws ec2 stop-instances --instance-ids i-01519f663af48a55e
{
    "StoppingInstances": [
        {
            "InstanceId": "i-1234567890abcdef0",
            ...
$ aws ec2 describe-instances --instance-ids i-01519f663af48a55e
{
   "Instances": [
        {
            ...
            "State": {
            "Code": 80, 
            "Name": "stopped"
            }
            ...
$ aws ec2 modify-instance-attribute --instance-ids i-01519f663af48a55e \
      --instance-type "{\"Value\": \"m5n.xlarge\"}"
$ aws ec2 start-instances --instance-ids i-01519f663af48a55e
{
    "StartingInstances": [
        {
            "InstanceId": "i-1234567890abcdef0",
            "CurrentState": {
                "Code": 0,
                "Name": "pending"
            },
            "PreviousState": {
                "Code": 80,
                "Name": "stopped"
            ...
$ aws ec2 describe-instances --instance-ids i-01519f663af48a55e
{
   "Instances": [
        {
            "AmiLaunchIndex": 0,
            "ImageId": "ami-0abcdef1234567890,
            "InstanceId": "i-1234567890abcdef0,
            "InstanceType": "m5n.xlarge",
            ...

También se puede hacer este cambio mediante la llamada a la API de AWS ModifyInstanceAttribute o con la consola AWS EC2

GCP

Para modificar el tipo de máquina de un servidor GCP (también conocida como una instance), se puede usar el comando gcloud CLI para detener, modificar y reiniciar la instancia. Por ejemplo, se podrían usar los siguientes comandos para modificar el tipo de máquina de una instancia llamada scalingTest por n1-highmem-96:

$ gcloud compute instances stop scalingTest
$ gcloud compute instances set-machine-type scalingTest --machine-type n1-highmem-32
$ gcloud compute instances start scalingTest

También se puede hacer este cambio usando la Google Cloud Console o la API de la GCP.

Azure

Cuando se utiliza Azure CLI para modificar el tamaño de una máquina virtual con Linux, se puede ver una lista de los tamaños disponibles en el clúster de hardware donde se aloja la máquina virtual usando el comando list-vm-resize-options, por ejemplo:

az vm list-vm-resize-options --resource-group testingGroup --name scalingTest --output table

Se puede utilizar el comando resize para cambiar el tamaño de la máquina virtual a una de las opciones en la lista, como se muestra en el ejemplo. Este comando reinicia la máquina virtual automáticamente.

az vm resize --resource-group testingGroup --name scalingTest --size Standard_E32d_v4

Si el tamaño al que quieres cambiar la máquina virtual no está disponible, puede anular la asignación de la máquina virtual, que puede ser redimensionada a cualquier tamaño que esté soportado por la región y reiniciarse. Los comandos relacionados se muestran a continuación:

az vm deallocate --resource-group testingGroup --name scalingTest
az vm resize --resource-group testingGroup --name scalingTest --size Standard_M128s
az vm start --resource-group testingGroup --name scalingTest

Se puede cambiar el tamaño de una máquina virtual de Windows en Azure utilizando el portal de Azure o los comandos de Powershell.

vSphere

Para cambiar el tamaño de una máquina virtual de VMware vSphere, hay que hacer lo siguiente:

  1. Abrir el cliente vSphere o el cliente web y mostrar el inventario de la máquina virtual.
  2. Haga clic con el botón derecho en la máquina virtual que quieres modificar y seleccionar Edit Settings.
  3. En la etiqueta Virtual Hardware
    • Expande Memory y cambia la cantidad de RAM configurada para la máquina virtual.
    • Expande CPU y cambia el número de núcleos y, de manera opcional, el número de núcleos por socket.
    • Realiza cualquier otro cambio que quieras en los recursos de hardware asignados a la máquina virtual.

Cómo reconfigurar InterSystems IRIS para aprovechar los recursos escalados

Cuando hayas escalado el servidor, el siguiente paso es reconfigurar InterSystems IRIS para aprovechar el aumento de recursos cambiando uno o más parámetros en el archivo de parámetros de configuración de la instancia (CPF). Por ejemplo, para continuar con el escenario mencionado al principio de esta publicación, ahora que has aumentado los recursos de memoria del servidor, querrás aprovecharte de esto aumentando el tamaño de la caché de la base de datos de la instancia de InterSystems IRIS (que se realiza cambiando el valor del parámetro globals) para que pueda mantener más datos en la memoria.

Una manera sencilla de realizar este tipo de cambios, y con mucho la forma más fácil y repetible para realizar varios cambios en la configuración de una instancia en una sola operación o de realizar los mismos cambios en varias instancias, es utilizar la función Combinar la configuración, que está disponible en los sistemas UNIX® y Linux. Como se describe en Cómo usar la función Combinar la configuración para implementar instancias personalizadas de InterSystems IRIS en Cómo ejecutar productos de InterSystems en contenedores y en Cómo usar la función Combinar la configuración en la Referencia del Archivo de Configuración de Parámetros, la función Combinar la configuración permite especificar un archivo de combinación que contenga la configuración que quieres combinar en el CPF de una instancia, inmediatamente antes de un reinicio.  (En la versión 2021.1 podrás hacer esto en una instancia que está en ejecución sin reiniciarla). Esto no solo es más conveniente que editar directamente el CPF de una instancia, sino que es altamente repetible en varias instancias, y es compatible con una gestión de cambios confiables, ya que permite mantener un historial preciso de los cambios simplemente adaptando la configuración de los archivos combinados a los que los aplique.

Para realizar la función Combinar la configuración, hay que hacer lo siguiente:

  1. Crear el archivo combinado con los parámetros que quieres modificar.
  2. Colocar el archivo combinado en una ubicación accesible a la instancia. Si la instancia que estás modificando se encuentra en un contenedor (el cual es probable que esté en un host de la nube), puedes preparar el archivo en el directorio %SYS duradero de la instancia (consulta %SYS duradero para datos persistentes de la instancia en Cómo ejecutar productos de InterSystems en contenedores).
  3. Especifique la ubicación del archivo combinado utilizando la variable de entorno ISC_CPF_MERGE_FILE antes de reiniciar la instancia.

Por ejemplo, siguiendo con el caso de la caché de la base de datos que necesita una actualización, supongamos que queremos aumentar a 100 GB el tamaño de la caché de la base de datos de una instancia en un contenedor. La configuración, en la sección [config] del CPF, sería globals=102400, que establece la caché de la base de datos para bloques de 8 kilobytes en 102,400 MB, o 100 GB. (Como se explica en la descripción de los globals en la Referencia del Archivo de Configuración de Parámetros, el parámetro establece el tamaño de la caché para varios tamaños de bloque; sin embargo, si solo se proporciona un valor, se aplica al tamaño de bloque de 8 kilobytes, y se asume **** [zero] para los otros tamaños; globals=102400 es, por lo tanto, el equivalente a globals=0,0,102400,0,0,0).

Para realizar este cambio, se puede realizar lo siguiente en el host de la nube:

1. Crear una configuración en el archivo combinado, denominado por ejemplo mergefile2021.06.30.cpf, que contenga estas líneas:

[config]
globals=102400

2. Colocar el archivo combinado en el directorio %SYS duradero que se encuentra en el sistema de archivos del host, el cual si se instaló el volumen externo /data como /external en el contenedor y se usó la variable ISC_DATA_DIRECTORY para especificar /external/iris_durable como el directorio %SYS duradero para la instancia, sería /data/iris_durable.

3. Utilizar el comando docker exec en la línea de comandos del host para especificar la variable y reiniciar la instancia con el comando iris si el contenedor de la instancia se llama iris y la instancia se llama IRIS, por ejemplo, el comando tendrá el siguiente aspecto:

docker exec iris ISC_CPF_MERGE_FILE=/data/iris_durable/mergefile2021.06.30.cpf 
iris stop IRIS restart
  1. Cuando la instancia se reinicie, se podrá confirmar la nueva configuración de globals con este comando:
docker exec iris grep globals /data/iris_durable/iris.cpf
1
0 130
Anuncio Esther Sanchez · ago 5, 2022

¡Hola Comunidad!

Estamos encantados de anunciar que vuelven los webinars de la Comunidad!

Os invitamos al webinar Cómo escalar el servidor FHIR de InterSystems en Amazon Web Services con ECP.

Fecha: Jueves 18 de agosto, 14:00 (CEST)
👨‍🏫 Ponente: @sween, Full Stack Architect en Integration Required
➡️ El webinar será en inglés


0
0 147
Artículo Ricardo Paiva · jun 24, 2021 6m read

Publicación Original por: Anton Umnikov
Arquitecto Senior de soluciones en la nube en InterSystems
AWS CSAA, GCP CACE

AWS Glue es un proceso ETL (extraer, transformar y cargar) completamente gestionado, que hace sencillo y rentable clasificar los datos, limpiarlos, enriquecerlos y moverlos de forma fiable entre diferentes almacenes de datos.

En el caso de InterSystems IRIS, AWS Glue permite mover grandes cantidades de datos a IRIS desde fuentes de datos tanto en la nube como en las propias instalaciones (on-premise). Las fuentes de datos potenciales incluyen, pero no se limitan a, bases de datos on-prem, archivos CSV, JSON, Parquet y Avro que residen en buckets S3, bases de datos nativas en la nube como AWS Redshift y Aurora, y muchas otras.

Este artículo asume que tienes un conocimiento básico de AWS Glue, al menos en el nivel para completar los Tutoriales de introducción a AWS Glue . Nos centraremos en los aspectos técnicos de la configuración de los trabajos (Jobs) en AWS Glue para utilizar InterSystems IRIS como Datos Objetivo, o en otros términos, "receptor de datos".

Imagen de https://docs.aws.amazon.com/glue/latest/dg/components-key-concepts.html
 

Los Trabajos en AWS Glue se ejecutan "sin servidor". Todos los recursos necesarios para realizar el trabajo son suministrados de forma dinámica por AWS solo durante el tiempo en que el trabajo se ejecuta realmente; y se destruyen en el momento en que el trabajo se completa. Por eso, en lugar de provisionar, gestionar e incurrir en costes continuos por la infraestructura necesaria, se te factura solo por el tiempo en que el trabajo realmente se ejecuta y puedes dedicar tus esfuerzos a escribir el código del Trabajo. Durante el tiempo de "inactividad" no se consumen recursos, salvo los buckets S3, que almacenan el código del Trabajo y la configuración.

Aunque hay varias opciones disponibles, normalmente los Trabajos en Glue se ejecutan con un suministro dinámico en Apache Spark y se escriben en código PySpark. El Trabajo en Glue contiene la sección _"Extraer"_ (donde los datos se extraen de las fuentes de datos), una serie de _"Transformaciones"_ (construidas utilizando la API de Glue) y finalmente la parte _"Cargar"_ o _"receptor"_, en la que después de la transformación final los datos se escriben en el sistema objetivo.

Para permitir que AWS Glue interactúe con IRIS necesitamos asegurar lo siguiente:

  • Glue tiene acceso a la red de las instancias IRIS involucradas
  • El archivo JAR del controlador JDBC de IRIS es accesible para el Trabajo en Glue
  • El Trabajo en Glue utiliza la API compatible con InterSystems IRIS JDBC

Examinemos cada uno de los pasos necesarios.

Crear una conexión a IRIS

En la consola AWS, selecciona AWS Glue->Connections->Add Connection

Introduce el nombre de tu conexión y selecciona "JDBC" como Tipo de Conexión.

En la URL de JDBC introduce la cadena de conexión JDBC para tu instancia de IRIS, el nombre de usuario y la contraseña.

El siguiente paso es crucial, necesitas asegurarte de que Glue coloca sus endpoints en el mismo VPC que tu instancia de IRIS. Selecciona la VPC y la Subred de tu instancia de IRIS. Cualquier grupo de seguridad con una regla de entrada de autorreferencias para todos los puertos TCP se ejecutaría aquí. Por ejemplo, el grupo de seguridad de tu instancia de IRIS.

Rol de IAM con acceso al controlador JDBC

Si aún no lo has hecho, carga el archivo JAR del controlador JDBC de IRIS intersystems-jdbc-3.0.0.jar en el bucket S3. En este ejemplo, estoy usando el bucket s3://irisdistr. Sería distinto para tu cuenta.

Necesitas crear un rol de IAM para tu Trabajo en Glue, que pueda acceder a ese archivo, junto con otros buckets S3 que Glue utilizaría para almacenar scripts, registros, etc.

Asegúrate de que tiene acceso de lectura al bucket de tu controlador JDBC. En este caso, concedemos a esta función (GlueJobRole) acceso de solo lectura (ReadOnly) a todos los buckets, junto con el AWSGlueServiceRole predefinido. Puedes elegir limitar aún más los permisos de este rol.

Crear y configurar el Trabajo en Glue

Crear un nuevo Trabajo en Glue. Selecciona el rol de IAM, que creamos en el paso anterior. Deja todo lo demás de forma predeterminada.

En "Security configuration, script libraries, y job parameters (optional)" establece en "Dependent jars path" la ubicación del intersystems-jdbc-3.0.0.jar  en el bucket S3.

 

Para la fuente: utiliza una de tus fuentes de datos preexistentes. Si seguiste los tutoriales mencionados más arriba, ya tendrás al menos una.

Utiliza la opción "Create tables in your data target" y selecciona la conexión IRIS que has creado en el paso anterior. Deja todo lo demás de forma predeterminada.

Si nos has seguido hasta ahora, deberías llegar a una pantalla similar a esta:

 

¡Ya queda poco! Solo necesitamos hacer un sencillo cambio en el script para cargar datos en IRIS.

Cómo ajustar el script

El script que Glue generó para nosotros utiliza AWS Glue Dynamic Frame, extensión propietaria de AWS para Spark. Aunque ofrece algunos beneficios para los trabajos de ETL, también garantiza que no puedes escribir datos en ninguna base de datos para la que AWS no haya administrado la oferta de servicios.

Buenas noticias- en el momento de escribir los datos en la base de datos ya no son necesarios todos los beneficios de Dynamic Dataframe, como no aplicación de esquema para los datos "sucios" (en el momento de escribir los datos se supone que están "limpios") y podemos convertir fácilmente Dynamic Dataframe a un Dataframe nativo en Spark que no está limitado a los objetivos administrados por AWS y puede trabajar con IRIS.

Así que la línea que necesitamos cambiar es la línea 40 de la imagen más arriba. Un último consejo.

Este es el cambio que necesitamos hacer:

#datasink4 = glueContext.write_dynamic_frame.from_jdbc_conf(frame = dropnullfields3, catalog_connection = "IRIS1", connection_options = {"dbtable": "elb_logs", "database": "USER"}, transformation_ctx = "datasink4")
dropnullfields3.toDF().write \
    .format("jdbc") \
    .option("url", "jdbc:IRIS://172.30.0.196:51773/USER/") \
    .option("dbtable", "orders") \
    .option("user", irisUsername) \
    .option("password", irisPassword) \
    .option("isolationlevel","NONE") \
    .save()

Donde irisUsername e irisPassword son el nombre de usuario y las contraseñas para tu conexión JDBC en IRIS.

Nota: almacenar las contraseñas en el código fuente NO es conveniente. Te animamos a utilizar herramientas como AWS Secrets Manager para ello, pero entrar en este nivel de detalles de seguridad está más allá del alcance de este artículo. Este es un buen artículo sobre el uso de AWS Secrets Manager en AWS Glue.

Ahora pulsa el botón "Run Job", siéntate y relájate mientras AWS Glue efectúa el proceso ETL por ti.

Bueno... lo más probable es que cometas algunos errores al principio... Todos sabemos cómo funciona. Una errata por aquí, un puerto equivocado en el grupo de seguridad por allí... AWS Glue utiliza CloudWhatch para almacenar todos los registros de ejecución y de errores. Busca grupos de registro en: /aws-glue/jobs/error y _ /aws-glue/jobs/output_, para identificar lo que salió mal.

¡Disfruta de la programación de los procesos ETL en la nube!

1
0 495
Anuncio Esther Sanchez · jun 15, 2022

¡Hola Comunidad!

Acabamos de añadir dos sesiones nuevas y una mesa redonda a la agenda del Global Summit 2022.

Y si aún no os habéis inscrito, todavía hay tiempo.

NUEVA MESA REDONDA

Sesiones Generales, jueves 23 de junio

Gaining Acceptance & Adoption

Mesa redonda moderada por Mike Fuller, Regional Marketing Director

Ed Meagher, antiguo CIO, Department of Veteran Affairs

Gerd Karnitschnig, International, SPAR/ASPIAG - Head of Software Solutions International

Neil Sarkar, President & CEO, Rhode Island Quality Institute

NUEVAS SESIONES CON AMAZON WEB SERVICES (AWS)

0
0 99
Artículo Ricardo Paiva · ene 28, 2022 28m read

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.

1
0 477
Artículo Ricardo Paiva · mayo 3, 2022 7m read

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.

Instalación

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    &lt;none>   18d   v1.18.9-eks-d1db3c
ip-192-168-37-96.ca-central-1.compute.internal   Ready    &lt;none>   18d   v1.18.9-eks-d1db3c
ip-192-168-76-18.ca-central-1.compute.internal   Ready    &lt;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".

Bonus #1 IRIS en ARM

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.

Bonus #2 Copia de seguridad y restauración

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 &lt;&lt;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 '&lt;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 

Programación de la copia de seguridad/restauración

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-pvc

Este 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: 10Gi

A 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:

  • Crear una nueva implementación de IRIS
  • Añadir algunos datos a IRIS
  • Freeze Write Daemon, tome un snapshot, thaw Write Daemon
  • Crear un clon de implementación de IRIS, basado en el snapshot
  • Verificar que todos los datos todavía están allí

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!

0
0 324
Pregunta Daniel Seco · feb 3, 2022

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

2
0 180
Artículo Alberto Fuentes · oct 7, 2021 2m read

¡Hola desarrolladores!

Con frecuencia, cuando colaboramos con el repositorio de alguien en GitHub, seguimos el siguiente ciclo:

  1. Fork: crear nuestra bifurcación del repositorio
  2. Clone: clonar una copia local de nuestro repositorio bifurcado
  3. Realizar nuestros cambios y guardarlos con un Commit en nuestra copia local
  4. Push: publicar nuestros cambios al repositorio clonado de GitHub
  5. Hacer Pull-Request para solicitar incorporar nuestros cambios desde nuestro fork — bifurcación — al repositorio original
  6. Y si todo va bien se hará un Merge — fusión o incorporación — con nuestros cambios en el repositorio original

¡Todo esto es genial y funciona bien!

Y si queremos realizar una segunda colaboración justo después de llevar a cabo un Merge , es necesario que primero realicemos un Fetch upstream en nuestro repositorio clonado para que tengamos disponibles los cambios actualizados que incorporamos al repositorio original a través del Pull Request.

Los más frikies de git lo hacen muy fácilmente, pero muchos terminamos simplemente por eliminar nuestro primer fork y crear otro nuevo.

Hoy me he dado cuenta de que Github ha añadido una nueva funcionalidad en la interfaz de usuario con la que puedo realizar fácilmente el Fetch upstream para mantener mi fork actualizado respecto al clon original y seguir siendo capaz de enviar nuevos Pull-Requests.

Aquí es donde podéis encontrar el botón en GitHub:

¡Esto es de gran ayuda!

Simplemente quería compartir este consejo para ahorrarnos algo de trabajo 😃

Así que ahora lo tenéis más fácil aún, ¡podéis incorporar más modificaciones a proyectos de la comunidad!

0
0 303
Artículo Muhammad Waseem · oct 5, 2021 2m read

Oí hablar del Banco de Mensajes (Message Bank) cuando comenzamos a rediseñar una producción de Health Connect para que se ejecutara en contenedores en la nube. Como habría varios contenedores de IRIS, se nos indicó que utilizáramos el Banco de Mensajes como un sitio único para ver los mensajes y registros de todos los contenedores.

¿Cómo funciona Message Bank?

Añadí la operación del Banco de Mensajes a nuestra Producción de Interoperabilidad. Envía automáticamente mensajes y registros de eventos al Banco de Mensajes.

0
0 118
Anuncio Esther Sanchez · jun 3, 2021

¡Hola Comunidad!

Hemos extendido hasta el día 2 de junio la duración del concurso InterSystems FHIR Accelerator, así que el plazo ha terminado definitivamente y hoy empieza la fase de votación, que durará hasta este domingo 6 de junio.

Vamos a elegir las mejores soluciones desarrolladas usando InterSystems IRIS FHIR Accelerator Service (FHIRaaS) en AWS.

➡️ ¡Aquí puedes elegir y votar la mejor!

¿Cómo se vota?

0
0 102
Anuncio Esther Sanchez · sep 29, 2020

¡Hola Comunidad!

Por si os lo perdisteis o queréis volver a verlo, ya está disponible la grabación completa del webinar "Integra y mejora tu plataforma IoT" que realizamos ayer lunes.

Webinar: Integra y mejora tu plataforma IoT

Por cierto... ¿habéis entrado al Canal de YouTube de la Comunidad de Desarrolladores en español? En él podéis ver todos los webinars que hemos realizado (¡ya llevamos seis!), varios tutoriales y otros vídeos. Y si os suscribís al canal, podréis ver nuestros vídeos directamente en vuestro muro de "Suscripciones" cuando entréis en YouTube yes

¡Esperamos que os resulte útil!

0
0 115
Artículo Ricardo Paiva · ago 18, 2020 32m read

¡Hola Comunidad!

Las empresas necesitan crecer y administrar sus infraestructuras informáticas globales de forma rápida y eficiente, al mismo tiempo que optimizan y administran la manera en que invierten y gastan sus fondos. Los servicios de computación y de almacenamiento de Amazon Web Services (AWS) y Elastic Compute Cloud (EC2) satisfacen las necesidades de las aplicaciones más exigentes basadas en InterSystems IRIS, al proporcionar una infraestructura informática global sumamente sólida.

0
0 1254
InterSystems Official Jose-Tomas Salvador · mayo 26, 2020

AWS ha liberado oficialmente su segunda generación de procesadores Graviton2 basados en ARM y asociados al tipo de instancia Amazon EC2 M6g, que presume de ser hasta un 40% mejor en precio-rendimiento sobre la actual generación de instancias M5 basadas en Xeon. 

Hace pocos meses, Inthhis nos llevó a suportar arquitecturas ARM64 por primera vez.

¡Ahora puedes probar InterSystems IRIS e InterSystems IRIS for Health sobre instancias Amazon EC2 M6g basadas en Graviton2 accesibles a través del AWS Marketplace!

0
0 198