Buscar

In 2017, Forbes publicó un artículo en el que hablaba sobre la "Economía de las APIs": https://www.forbes.com/sites/louiscolumbus/2017/01/29/2017-is-quickly-becoming-the-year-of-the-api-economy/. Ese artículo fue el detonante que popularizó el uso de las APIs y la Gestión de APIs por las grandes compañías. En el artículo, se mostraba un Modelo de Madurez. Yo creo que Intersystems IRIS permite alcanzar la cima de la pirámide con tus tecnologías actuales. Mira la figura arriba. Por ello, es importante combinar el paquete % CSP.REST, IRIS API Manager (IAM), ML Pack e IntegratedML, Native API for Python, BPL y los adaptadores de interoperabilidad.

En el artículo anterior, vimos una forma de crear un operador personalizado que administra el estado de la instancia de IRIS. Esta vez, vamos a echar un vistazo a un operador listo para usar - el Operador InterSystems Kubernetes (IKO). La documentación oficial nos ayudará a recorrer los pasos de la implementación. Requisitos previos Para implementar IRIS, necesitamos un clúster de Kubernetes. En este ejemplo, utilizaremos Google Kubernetes Engine (GKE), por lo que tendremos que utilizar una cuenta de Google, configurar un proyecto de Google Cloud e instalar las herramientas de línea de comandos gcloud y kubectl. También necesitarás instalar la herramienta Helm3: $ helm version version.BuildInfo{Version:"v3.3.4"...} Nota: ten en cuenta que en el nivel gratuito de Google, no todos los recursos son gratuitos. En nuestro caso no importa el tipo de GKE que utilicemos: zonal, regional, o privada. Después de crear uno, vamos a conectarnos al clúster. Hemos creado un clúster llamado "iko" en un proyecto llamado "iko-project". En el siguiente texto, utiliza el nombre de tu propio proyecto en vez de "iko-project". Este comando añade el clúster a nuestra configuración de clústeres locales: $ gcloud container clusters get-credentials iko --zone europe-west2-b --project iko-project Instalar IKO Vamos a implementar IKO en nuestro clúster recién creado. La forma recomendada de instalar paquetes en Kubernetes es usando Helm. IKO no es una excepción y se puede instalar como un gráfico de Helm. Elige la versión 3 de Helm, ya que es más segura. Descarga IKO desde la página Componentes de InterSystems del Centro de Soporte Internacional (WRC), creando una cuenta de desarrollador gratuita si aún no tienes una. En el momento de escribir este artículo, la última versión era 2.0.223.0. Descarga y descomprime el archivo. Nos referiremos al directorio descomprimido como el directorio actual. El gráfico se encuentra en el directorio chart/iris-operator. Si solo implementas este gráfico, recibirás un error al describir los contendores implementados: Failed to pull image "intersystems/iris-operator:2.0.0.223.0": rpc error: code = Unknown desc = Error response from daemon: pull access denied for intersystems/iris-operator, repository does not exist or may require 'docker login'. Por lo tanto, es necesario hacer que una imagen IKO esté disponible desde el clúster Kubernetes. Primero, vamos a incorporar esta imagen al Google Container Registry: $ docker load -i image/iris_operator-2.0.0.223.0-docker.tgz $ docker tag intersystems/iris-operator:2.0.0.223.0 eu.gcr.io/iko-project/iris-operator:2.0.0.223.0 $ docker push eu.gcr.io/iko-project/iris-operator:2.0.0.223.0 Después, debemos indicar al IKO que utilice esta nueva imagen. Debes hacerlo editando el archivo de valores de Helm: $ vi chart/iris-operator/values.yaml ... operator: registry: eu.gcr.io/iko-project ... Ahora, estamos listos para implementar IKO en GKE: $ helm upgrade iko chart/iris-operator --install --namespace iko --create-namespace $ helm ls --all-namespaces --output json | jq '.[].status' "deployed" $ kubectl -n iko get pods # Should be Running with Readiness 1/1 Veamos los registros de IKO: $ kubectl -n iko logs -f --tail 100 -l app=iris-operator … I1212 17:10:38.119363 1 secure_serving.go:116] Serving securely on [::]:8443 I1212 17:10:38.122306 1 operator.go:77] Starting Iris operator La definición de recursos personalizados irisclusters.intersystems.com fue creada durante la implementación de IKO. Puedes consultar el esquema compatible con la API, aunque es bastante largo: $ kubectl get crd irisclusters.intersystems.com -oyaml | less Una forma de ver todos los parámetros disponibles es utilizar el comando "explain": $ kubectl explain irisclusters.intersystems.com Otra forma es utilizar jq. Por ejemplo, viendo todos los ajustes de la configuración de nivel superior: $ kubectl get crd irisclusters.intersystems.com -ojson | jq '.spec.versions[].schema.openAPIV3Schema.properties.spec.properties | to_entries[] | .key' "configSource" "licenseKeySecret" "passwordHash" "serviceTemplate" "topology" Al utilizar jq de esta manera (viendo los campos de configuración y sus propiedades), podemos encontrar la siguiente estructura de configuración: configSource name licenseKeySecret name passwordHash serviceTemplate metadata annotations spec clusterIP externalIPs externalTrafficPolicy healthCheckNodePort loadBalancerIP loadBalancerSourceRanges ports type topology arbiter image podTemplate controller annotations metadata annotations spec affinity nodeAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution podAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution podAntiAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution args env imagePullSecrets initContainers lifecycle livenessProbe nodeSelector priority priorityClassName readinessProbe resources schedulerName securityContext serviceAccountName tolerations preferredZones updateStrategy rollingUpdate type compute image podTemplate controller annotations metadata annotations spec affinity nodeAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution podAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution podAntiAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution args env imagePullSecrets initContainers lifecycle livenessProbe nodeSelector priority priorityClassName readinessProbe resources limits requests schedulerName securityContext serviceAccountName tolerations preferredZones replicas storage accessModes dataSource apiGroup kind name resources limits requests selector storageClassName volumeMode volumeName updateStrategy rollingUpdate type data image mirrored podTemplate controller annotations metadata annotations spec affinity nodeAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution podAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution podAntiAffinity preferredDuringSchedulingIgnoredDuringExecution requiredDuringSchedulingIgnoredDuringExecution args env imagePullSecrets initContainers lifecycle livenessProbe nodeSelector priority priorityClassName readinessProbe resources limits requests schedulerName securityContext serviceAccountName tolerations preferredZones shards storage accessModes dataSource apiGroup kind name resources limits requests selector storageClassName volumeMode volumeName updateStrategy rollingUpdate type Hay muchos ajustes, pero no necesitas configurar todos. Los valores predeterminados son adecuados. Puedes ver ejemplos de configuración en el archivo iris_operator-2.0.0.223.0/samples. Para ejecutar un IRIS viable mínimo, necesitamos especificar solo unos pocos ajustes, como la versión de IRIS (o de la aplicación basada en IRIS), el tamaño del almacenamiento y la clave de licencia. Nota sobre la clave de la licencia: utilizaremos la versión Community de IRIS, por lo que no necesitamos una clave. Como no podemos omitir esta configuración, vamos a crear una información confidencial que contenga una pseudo-licencia. La generación de la información confidencial de la licencia es sencilla: $ touch iris.key # remember that a real license file is used in the most cases $ kubectl create secret generic iris-license --from-file=iris.key Una descripción de IRIS entendible por IKO es: $ cat iko.yaml apiVersion: intersystems.com/v1alpha1 kind: IrisCluster metadata: name: iko-test spec: passwordHash: '' # use a default password SYS licenseKeySecret: name: iris-license # use a Secret name bolded above topology: data: image: intersystemsdc/iris-community:2020.4.0.524.0-zpm # Take a community IRIS storage: resources: requests: storage: 10Gi Envía este manifiesto al clúster: $ kubectl apply -f iko.yaml $ kubectl get iriscluster NAME DATA COMPUTE MIRRORED STATUS AGE iko-test 1 Creating 76s $ kubectl -n iko logs -f --tail 100 -l app=iris-operator db.Spec.Topology.Data.Shards = 0 I1219 15:55:57.989032 1 iriscluster.go:39] Sync/Add/Update for IrisCluster default/iko-test I1219 15:55:58.016618 1 service.go:19] Creating Service default/iris-svc. I1219 15:55:58.051228 1 service.go:19] Creating Service default/iko-test. I1219 15:55:58.216363 1 statefulset.go:22] Creating StatefulSet default/iko-test-data. Vemos que algunos recursos (Service, StatefulSet) se van a crear en un clúster en el namespace "predeterminado". En pocos segundos, deberías ver un contenedor de IRIS en el namespace "predeterminado": $ kubectl get po -w NAME READY STATUS RESTARTS AGE iko-test-data-0 0/1 ContainerCreating 0 2m10s Espera un poco hasta que se extraiga la imagen de IRIS, es decir, hasta que el Estado sea Ready y Ready sea 1/1. Puedes verificar qué tipo de disco se creó: $ kubectl get pv NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-b356a943-219e-4685-9140-d911dea4c106 10Gi RWO Delete Bound default/iris-data-iko-test-data-0 standard 5m La política de recuperación “Delete” (Eliminar) significa que cuando se elimina el Volumen Persistente, el disco persistente GCE también se eliminará. Hay otra política, “Retain” (Retener), que te permite guardar discos persistentes de Google para conservar los volúmenes persistentes eliminados de Kubernetes. Puedes definir una StorageClass personalizada para utilizar esta política y otras configuraciones no predeterminadas. Un ejemplo está presente en la documentación de IKO: Crear una clase de almacenamiento para el almacenamiento persistente. Ahora, vamos a comprobar nuestro IRIS recién creado. En general, el tráfico hacia los contenedores pasa a través de los Services o Ingresses. De forma predeterminada, IKO crea un servicio de tipo ClusterIP con un nombre del campo iko.yaml metadata.name: $ kubectl get svc iko-test NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE iko-test ClusterIP 10.40.6.33 <none> 1972/TCP,52773/TCP 14m Podemos llamar a este servicio usando port-forward: $ kubectl port-forward svc/iko-test 52773 Ve a http://localhost:52773/csp/sys/UtilHome.csp y escribe _system/SYS. Deberías ver una interfaz de usuario (IU) de IRIS que te resultará familiar. Aplicación personalizada Vamos a sustituir un IRIS puro por una aplicación basada en IRIS. En primer lugar, descarga la aplicación COVID-19.. No vamos a considerar aquí una implementación completa y continua, solo consideraremos unos pasos mínimos: $ git clone https://github.com/intersystems-community/covid-19.git $ cd covid-19 $ docker build --no-cache -t covid-19:v1 . Como nuestro Kubernetes se ejecuta en una nube de Google, vamos a utilizar Google Docker Container Registry como un almacén de imágenes. Asumimos aquí que tienes una cuenta en Google Cloud que te permite enviar imágenes. Utiliza tu propio nombre de proyecto en los siguientes comandos: $ docker tag covid-19:v1 eu.gcr.io/iko-project/covid-19:v1 $ docker push eu.gcr.io/iko-project/covid-19:v1 Vamos al directorio con iko.yaml, cambiamos la imagen que se encuentra allí y volvamos a implementarla. Debes considerar eliminar primero el ejemplo anterior: $ cat iko.yaml ... data: image: eu.gcr.io/iko-project/covid-19:v1 ... $ kubectl delete -f iko.yaml $ kubectl -n iko delete deploy -l app=iris-operator $ kubectl delete pvc iris-data-iko-test-data-0 $ kubectl apply -f iko.yaml Deberás volver a crear el contenedor IRIS con esta nueva imagen. Esta vez, vamos a proporcionar acceso externo por medio del Ingress Resource. Para que funcione, debemos implementar un Ingress Controller (elige nginx por su flexibilidad). Para proporcionar un cifrado de tráfico (TLS), también añadiremos otro componente – cert-manager. Para instalar estos dos componentes, utilizamos una herramienta Helm, versión 3. $ helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx $ helm upgrade nginx-ingress \ --namespace nginx-ingress \ ingress-nginx/ingress-nginx \ --install \ --atomic \ --version 3.7.0 \ --create-namespace Observa una IP de servicio nginx (es dinámica, pero puedes hacerla estática): $ kubectl -n nginx-ingress get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx-ingress-ingress-nginx-controller LoadBalancer 10.40.0.103 xx.xx.xx.xx 80:32032/TCP,443:32374/TCP 88s Nota: tu IP será distinta. Ve a tu registrador de dominios para dar de alta y crear un nombre de dominio para esta IP. Por ejemplo, crea un registro A: covid19.myardyas.club = xx.xx.xx.xx Pasará algún tiempo hasta que este nuevo registro se propague a los servidores DNS. El resultado final debería ser similar a: $ dig +short covid19.myardyas.club xx.xx.xx.xx Después de implementar el Ingress Controller, ahora necesitamos crear un Ingress Resource en sí mismo (usa tu propio nombre de dominio): $ cat ingress.yaml apiVersion: extensions/v1beta1 kind: Ingress metadata: name: iko-test annotations: kubernetes.io/ingress.class: nginx nginx.ingress.kubernetes.io/use-regex: "true" nginx.ingress.kubernetes.io/ssl-redirect: "true" certmanager.k8s.io/cluster-issuer: lets-encrypt-production # Cert manager will be deployed below spec: rules: - host: covid19.myardyas.club http: paths: - backend: serviceName: iko-test servicePort: 52773 path: / tls: - hosts: - covid19.myardyas.club secretName: covid19.myardyas.club $ kubectl apply -f ingress.yaml Después de un minuto, más o menos, IRIS debería estar disponible en http://covid19.myardyas.club/csp/sys/UtilHome.csp (recuerda utilizar tu nombre de dominio) y la aplicación COVID-19 en http://covid19.myardyas.club/dsw/index.html (selecciona el namespace IRISAPP). Nota: arriba, expusimos el puerto HTTP de IRIS. Si necesitas exponer a través de nginx el puerto super-servidor TCP (1972 o 51773), lee las instrucciones en Exponer servicios TCP y UDP. Añadir cifrado de tráfico El último paso es añadir cifrado de tráfico. Para ello, vamos a implementar cert-manager: $ kubectl apply -f https://raw.githubusercontent.com/jetstack/cert-manager/v0.10.0/deploy/manifests/00-crds.yaml $ helm upgrade cert-manager \ --namespace cert-manager \ jetstack/cert-manager \ --install \ --atomic \ --version v0.10.0 \ --create-namespace $ cat lets-encrypt-production.yaml apiVersion: certmanager.k8s.io/v1alpha1 kind: ClusterIssuer metadata: name: lets-encrypt-production spec: acme: # Set your email. Let’s Encrypt will send notifications about certificates expiration email: mvhoma@gmail.com server: https://acme-v02.api.letsencrypt.org/directory privateKeySecretRef: name: lets-encrypt-production solvers: - http01: ingress: class: nginx $ kubectl apply -f lets-encrypt-production.yaml Espera unos minutos hasta que cert-manager note el acceso de la aplicación de IRIS Ingress y vaya a Let's Encrypt para obtener un certificado. Puedes observar los recursos Order y Certificate en curso: $ kubectl get order NAME STATE AGE covid19.myardyas.club-3970469834 valid 52s $ kubectl get certificate NAME READY SECRET AGE covid19.myardyas.club True covid19.myardyas.club 73s Esta vez, puedes visitar una versión más segura del sitio - https://covid19.myardyas.club/dsw/index.html: Sobre el controlador de acceso nativo de Google y los certificados administrados Google admite su propio controlador de acceso, GCE, que puedes utilizar en vez de un controlador nginx. Sin embargo, tiene algunos inconvenientes, por ejemplo, la falta de compatibilidad con las reglas para reescribir, al menos en el momento de escribir. Además, puedes utilizar certificados administrados por Google en lugar de cert-manager. Es útil, pero la recuperación inicial del certificado y cualquier actualización de los recursos de Ingress (como la nueva ruta) provoca un tiempo de inactividad evidente. Además, los certificados administrados por Google solo funcionan con GCE, no con nginx, como se indica en los certificados administrados. Siguientes pasos Hemos implementado una aplicación basada en IRIS en el clúster GKE. Para exponerlo en Internet, hemos añadido un Ingress Controller y un administrador de certificaciones. Hemos probado la configuración de IrisCluster para resaltar que la configuración de IKO es sencilla. Puedes leer sobre más configuraciones en la documentación: Uso del Operador InterSystems Kubernetes. Un solo servidor de datos está bien, pero la verdadera diversión comienza cuando añadimos ECP, mirroring y monitorización, que también están disponibles con IKO. En el próximo artículo trataremos mirroring en detalle.

Buenas tardes, Puedo conectarme a una base de datos InterSystems Cache DB por medio de PHP o algún otro lenguaje? Muchas gracias por su ayuda Saludos Roman Por supuesto! Siempre puedes usar JDBC o ODBC. Dame más datos para poder ayudarte. Buenas tardes David, Necesito hacer un pipeline entre Intersystem y MySQL por PHP. Es posible hacer esto? Muchas Gracias por tu ayuda Saludos A qué te refieres con pipeline por PHP???? si quieres conectar una BD MySQL con Caché se puede hacer de varias formas. Por ejemplo mediante tablas vinculadas. De esta forma tablas de una BD externa se ven como tablas propias de Caché. Pero sigo sin saber muy bien que necesitas Buen día David, gracias por tu respuesta!! Básicamente, necesito consultar tablas de Avaya Aura Contact Center (InterSystem Cache ) y todos esos datos pasarlos a otra base de datos (MySQL) via PHP. Saludos Roman Lo de pasar los datos “vía PHP” es lo que me suena muy raro. Si quieres migrar los datos de una BD a la otra se me ocurren mil mejores formas que con PHP. Si lo que necesitas es conectarte a Caché para recuperar información a una pantalla de PHP y luego moverla a MySQL. El problema se reduce a conectar PHP a Caché. Mírate este proyecto de código abierto: https://github.com/chrisemunt/mg_php Buen día David, Siguiendo los pasos del readme del proyecto: 1) instalar gcc (listo)2) descargar el codigo desde GitHub (listo)3) nos paramos en el directorio src del proyecto, y ejecutamos phpize (listo)4) parados en el mismo directorio ejecutamos ./configure (listo)5) luego ejecutamos make (para preparar la instalación), y es aca donde tenemos varios errores que no nos dejan seguir. Me imagino que por algunas dependencias que faltan, que no sabría cuales porque tampoco están detalladas como requisitos. Me podrías orientar en este punto? Adjunto captura de pantalla con error Desde ya muchas gracias Por otro lado, entiendo que todas estas herramientas no están estandarizadas en repositorios de linux, se las debe instalar manualmente. Hola Román, La verdad es que no sabría ayudarte en esto. Normalmente si tienes un problema con un proyecto de GitHub abres un caso en ese proyecto para que el autor te ayude. En este caso sería aquí: https://github.com/chrisemunt/mg_php/issues

Ya están disponibles nuevas versiones de mantenimiento de: Caché 2018.1.5, Ensemble 2018.1.5 y HSAP 2018.1.5 InterSystems IRIS 2019.1.2, IRIS for Health 2019.1.2 y HealthShare Health Connect 2019.1.2 InterSystems IRIS 2020.1.1, IRIS for Health 2020.1.1 y HealthShare Health Connect 2020.1.1 Los kits para la instalación y los contenedores se pueden descargar de la página de distribución de software del Centro de Soporte Internacional (WRC). Son versiones de mantenimiento con muchas actualizaciones en una gran variedad de áreas. Para más información sobre las correcciones incluidas en estas versiones, consulta por favor la documentación de cada versión, que incluye las Notas de la Versión, el Listado de Cambios de la Versión, la Referencia de Clases y toda una serie de guías, referencias, tutoriales y artículos. Toda la documentación se encuentra en docs.intersystems.com. Se han añadido nuevas plataformas compatibles con las nuevas versiones. En concreto, Ubuntu 20.04 LTS ahora es compatible con todas las versiones, IBM AIX 7.1 y 7.2 for System p-64 es compatible con la versión 2019.1.2 (ya era compatible con la 2020.1) y ARM64 support for Linux es compatible con la versión 2020.1.1. Para más detalles, consulta el documento de Plataformas Compatibles de cada versión. Los números de compilación de estas versiones se muestran en la siguiente tabla: Versión Producto Nº de compilación 2018.1.5 Caché y Ensemble 2018.1.5.659.0 2018.1.5 Caché Evaluation 2018.1.5.659.0su 2018.1.5 HealthShare Health Connect (HSAP) 2018.1.5HS.9056.0 2019.1.2 InterSystems IRIS 2019.1.2.718.0 2019.1.2 IRIS for Health 2019.1.2.718.0 2019.1.2 HealthShare Health Connect 2019.1.2.718.0 2020.1.1 InterSystems IRIS 2020.1.1.408.0 2020.1.1 IRIS for Health 2020.1.1.408.0 2020.1.1 HealthShare Health Connect 2020.1.1.408.0 2020.1.1 InterSystems IRIS Community 2020.1.1.408.0 2020.1.1 IRIS for Health Community 2020.1.1.408.0 2020.1.1 IRIS Studio 2020.1.1.408.0

Se acaba de liberar la versión 2.3 de InterSystems API Manager (IAM). El contenedor para IAM, incluyendo todo lo necesario para actualizar desde versiones anteriores de IAM, puede descargarse desde la Página de distribución de software del Centro de Soporte Internacional (WRC), en el área de Components. El número de compilación de esta versión es IAM 2.3.3.2-1. Esta versión está basada en la versión 2.3.3.2 de Kong Enterprise. InterSystems API Manager 2.3 hace más sencillo implementar de una forma segura y para escenarios de alta disponibilidad (HA). Incluye muchas funcionalidades nuevas, como: Introducción del modo híbrido Mayor soporte a Docker Secrets El modo híbrido permite implementar los nódulos de IAM en un nivel de datos (data plane) y un nivel de control (control plane). Mientras que el data plane se ocupa del tráfico de las API, el control plane se utiliza para configurar los nodos del data plane y observar la telemetría desde el data plane. Esto permite una mayor fexibilidad en las implementaciones y reduce el esfuerzo para la creación de escenarios de alta disponibilidad (HA). Aquí podéis encontrar más información sobre el modo híbrido. Esta funcionalidad será tratada con más detalle en la Comunidad de Desarrolladores durante los próximos días. La documentación para IAM 2.3 está disponible aquí. Esta documentación solo cubre elementos que son específicos de IAM. Los enlaces a la documentación en el producto llevan directamente a la documentación de Kong Enterprise. Actualizar desde IAM 1.5.0.9 requiere actualizaciones incrementales a través de dos versiones intermedias, como se describe con más detalle en la documentación. IAM solo está disponible en OCI (Open Container Initiative), es decir, en formato contenedor Docker. Las imágenes para contenedor están disponibles para motores del run-time compatibles con Linux x86-64 y Linux ARM64, como se detalla en el documento de plataformas soportadas.

Siguiendo la serie de artículos de mi compañero Murray vamos a centrarnos en el artículo donde analizamos la CPU. Un cliente me pidió que le aconsejara sobre el siguiente escenario: sus servidores de producción se están acercando al final de su vida útil y es el momento de actualizar el hardware. También están pensando en consolidar los servidores por medio de la virtualización y quieren ajustar la capacidad, ya sea con servidores de hardware dedicado o virtualizados. Hoy analizaremos la CPU. En artículos posteriores explicaré el enfoque para dimensionar correctamente otros "grupos alimenticios de hardware": la memoria y las Entradas/Salidas. Entonces las preguntas son: - ¿Cómo se traducen los requisitos de un procesador de hace más de cinco años a los procesadores actuales? - De los procesadores actuales, ¿cuáles son adecuados? - ¿Cómo afecta la virtualización a la planificación de la capacidad de la CPU? **Añadido en junio de 2017**: Para profundizar en los aspectos específicos de las consideraciones y la planificación de la CPU en VMware y para conocer algunas preguntas y problemas comunes, puedes consultar esta publicación: [Virtualización de grandes bases de datos: Planificación de la capacidad de la CPU en VMware](https://community.intersystems.com/post/virtualizing-large-databases-vmware-cpu-capacity-planning) [Aquí puedes ver un listado con otros artículos de esta serie >>](https://community.intersystems.com/post/capacity-planning-and-performance-series-index) # Cómo comparar el rendimiento de la CPU usando los análisis de rendimiento (*benchmarks*) spec.org Para traducir el uso de la CPU entre los distintos tipos de procesadores para aplicaciones desarrolladas con las plataformas de datos de InterSystems (Caché, Ensemble, HealthShare), puedes usar los análisis de rendimiento de SPECint como un cálculo aproximado para escalar entre procesadores. La página web [http://www.spec.org](http://www.spec.org) ofrece resultados fiables de un conjunto de análisis de rendimiento estandarizados, ejecutados por proveedores de hardware. Específicamente, SPECint es una forma de comparar distintos modelos de procesadores de los mismos proveedores y de diferentes proveedores (por ejemplo: Dell, HP, Lenovo e Intel, AMD, IBM POWER y SPARC). Puedes utilizar SPECint para entender los requisitos esperados de la CPU para tu aplicación cuando se vaya a actualizar el hardware o si tu aplicación se implementará en varios hardwares de distintos clientes y necesitas establecer una línea de base para una métrica de tamaño, por ejemplo, máximo número de transacciones por núcleo de la CPU para Intel Xeon E5-2680 (o cualquier procesador que elijas). En el sitio web de SPECint se utilizan varios análisis de rendimiento, pero los resultados de **SPECint_rate_base2006** son los mejores para Caché, ya que se han confirmado a lo largo de muchos años analizando datos de clientes y en nuestros propios análisis de rendimiento. Como ejemplo, en este artículo vamos a comparar la diferencia entre el servidor Dell PowerEdge de los clientes con procesadores Xeon 5570, y un servidor Dell actual con procesadores Intel Xeon E5-2680 V3. La misma metodología se puede aplicar con los procesadores de servidor Intel Xeon V4 disponibles de forma generalizada. ## Ejemplo: Comparando procesadores Busca __SPECint2006_Rates__ en la base de datos de spec.org, por nombre del procesador, por ejemplo __E5-2680 V3__. Puedes afinar aún más los resultados de tu búsqueda si conoces la marca y el modelo de tu servidor objetivo (por ejemplo, Dell R730); si no, utiliza un proveedor popular. En mi experiencia, creo que los modelos de Dell o HP son buenas bases de referencia de servidores estándar, generalmente no hay gran variación entre los procesadores de diferentes proveedores de hardware. > Al final de esta publicación mostraré un ejemplo paso a paso de cómo buscar resultados con el sitio web spec.org Supongamos que buscaste en spec.org y encontraste el servidor actual y un posible servidor nuevo, así: Actual: Dell PowerEdge R710 con Xeon 5570, 2.93 GHz: 8 núcleos, 2 chips, 4 núcleos/chips, 2 hilos/núcleos: __SPECint_rate_base2006 = 251__ Nuevo: PowerEdge R730 con Intel Xeon E5-2680 v3, 2.50 GHz: 24 núcleos, 2 chips, 12 núcleos/chips, 2 hilos/núcleos: __SPECint_rate_base2006 = 1030__ No sorprende que el nuevo servidor de 24 núcleos aumente más de 4 veces el rendimiento del análisis de rendimiento SPECint_rate_base2006 con respecto al servidor anterior de 8 núcleos, a pesar de que el servidor nuevo tiene una menor velocidad del reloj. Ten en cuenta que los ejemplos son servidores de dos procesadores que tienen ambas ranuras del procesador ocupadas. ### ¿Por qué se utiliza SPECint_rate_base2006 para Caché? El sitio web spec.org tiene explicaciones de las distintos análisis de rendimiento, pero el resumen es que el análisis de rendimiento **SPECint_rate2006** es un punto de referencia completo a nivel de sistema que utiliza todos los CPU con HyperThreading. Para un análisis de rendimiento SPECint_rate2006 en particular, se reportan dos métricas: _base_ y _pico_. Base es un análisis de rendimiento conservador, mientras que Pico es agresivo. Para planificar la capacidad, utiliza los resultados de __SPECint_rate_base2006.__. ## ¿Un SPECint_rate_base2006 cuatro veces mayor significa una capacidad cuatro veces mayor para usuarios o transacciones? Posiblemente si se utilizaran los 24 núcleos, el rendimiento de la aplicación pudiera escalar a cuatro veces la capacidad del servidor anterior. Sin embargo, hay varios factores que pueden hacer que los resultados sean distintos. SPECint te permitirá conocer el tamaño y el rendimiento que debería ser posible, pero hay algunas advertencias. Aunque SPECint ofrece una buena comparación entre los dos servidores del ejemplo anterior, no garantiza que el servidor E5-2680 V3 tenga un 75% más de capacidad para los picos de usuarios concurrentes o para el pico de rendimiento de las transacciones que el servidor anterior basado en Xeon 5570. Hay que tener en cuenta otros factores, como el hecho de que los demás componentes de hardware de nuestros "grupos alimenticios de hardware" estén actualizados, por ejemplo, si el almacenamiento nuevo o el actual es capaz de dar servicio al aumento del rendimiento (pronto publicaré un análisis profundo sobre el almacenamiento). Basado en mi experiencia analizando el rendimiento de Caché y observando los datos de rendimiento de los clientes, __Caché es capaz de escalar linealmente a tasas de rendimiento extremadamente altas en un solo servidor__ a medida que se añaden recursos informáticos (núcleos de la CPU). Esto es aún más cierto con las mejoras que Caché recibe año tras año. Dicho de otro modo, veo un escalado lineal del rendimiento máximo de la aplicación, por ejemplo de las transacciones de la aplicación o reflejado en las *glorefs* (referencias globales) de Caché conforme se añaden núcleos en la CPU. Sin embargo, si hay cuellos de botella en las aplicaciones, pueden empezar a aparecer con tasas de transacción más altas y repercutir en el escalado lineal. En artículos posteriores explicaré dónde se pueden buscar síntomas de cuellos de botella en las aplicaciones. Una de las mejores medidas que se pueden tomar para mejorar la capacidad de rendimiento de las aplicaciones es actualizar Caché a la última versión. > **Nota:** Para Caché, los servidores Windows 2008 con más de 64 núcleos lógicos no son compatibles. Por ejemplo, un servidor de 40 núcleos debe tener desactivado el Hyper Threading. Para Windows 2012 se admiten hasta 640 procesadores lógicos. No hay límites en Linux. ## ¿Cuántos núcleos necesita la aplicación? Las aplicaciones varían y cada uno conoce el perfil de sus propias aplicaciones, pero el enfoque común que utilizo cuando planifico la capacidad de la CPU para un servidor (o máquina virtual) es a partir de la monitorización cuidadosa del sistema, comprender que un cierto número de núcleos de CPU de un determinado procesador "estándar" puede sostener una tasa de transacción máxima de _n_ transacciones por minuto. Estas podrían ser episodios, o encuentros, o pruebas de laboratorio o lo que sea. El punto es que el rendimiento del procesador estándar se basa en las métricas que ha recogido en tu sistema actual o un sistema de clientes. Si conoces el pico de uso de recursos actual de la CPU en un procesador conocido con _n_ núcleos, se puede traducir al número de núcleos necesarios en un procesador más nuevo o diferente para la misma tasa de transacciones utilizando los resultados de SPECint. Con un escalado lineal esperado, 2 x _n_ transacciones por minuto se traduce aproximadamente en 2 x el número de núcleos necesarios. ## Cómo elegir un procesador Como se puede ver en spec.org o analizando la oferta de tu proveedor, hay muchas opciones de procesadores. El cliente de este ejemplo está contento con Intel, por lo que me limitaré a recomendarle servidores Intel actuales. Una forma de proceder es buscar la mejor relación coste-beneficio, o la mejor relación SPECint_rate_base2006 por dólar y por núcleo. Por ejemplo, el siguiente gráfico muestra los servidores básicos de Dell - tu precio variará, pero esto ilustra que hay puntos más favorables en el precio y recuentos de núcleo más altos adecuados para la consolidación de los servidores utilizando la virtualización. Creé el gráfico fijando el precio de un servidor de producción de calidad, por ejemplo, el Dell R730, y luego examinando distintas opciones de procesadores.  Según los datos del gráfico y la experiencia en sitios de los clientes, el procesador E5-2680 V3 presenta un buen rendimiento a un precio adecuado por SPECint, o por núcleo. También entran en juego otros factores, por ejemplo, si estás buscando procesadores de servidor para la implementación virtualizada, puede ser más barato aumentar el número de núcleos por procesador, lo que tiene un coste mayor pero logra reducir el número total de servidores necesarios para soportar todas tus máquinas virtuales. De esta forma ahorrarás en software (p. ej. VMware o sistemas operativos) que cobran licencias por ranura de procesador. También tendrás que equilibrar el número de servidores con los requisitos de alta disponibilidad (HA). En artículos posteriores volveré a hablar de VMware y HA. Por ejemplo, un clúster de VMware HA formado por tres servidores host de 24 núcleos proporciona una buena disponibilidad y una potencia de procesamiento significativa (por número de núcleos), permitiendo configuraciones flexibles de máquinas virtuales de producción y de no producción. Recuerda que VMware HA tiene un tamaño de N+1 servidores, por lo que tres servidores de 24 núcleos equivalen a un total de 48 núcleos disponibles para tus máquinas virtuales. ## Núcleos vs GHz: ¿Qué es lo mejor para Caché? Si tienes que elegir entre núcleos de CPU más rápidos o más núcleos de CPU, debes considerar lo siguiente: - Si tu aplicación requiere muchos hilos/procesos de cache.exe, un mayor número de núcleos permitirá que más de ellos se ejecuten exactamente al mismo tiempo. - Si tu aplicación tiene menos procesos, desearás que cada uno se ejecute lo más rápido posible. Otra forma de ver esto es pensar que si tienes una aplicación de tipo cliente/servidor con muchos procesos, por ejemplo, uno o más por usuario simultáneo, querrás tener más núcleos disponibles. Para aplicaciones basadas en el navegador que utilizan CSP, en las que los usuarios se agrupan en menos procesos de servidor CSP muy ocupados, tu aplicación se beneficiaría de tener un número potencialmente menor de núcleos, pero más rápidos. En un mundo ideal, ambos tipos de aplicaciones se beneficiarían de contar con muchos núcleos rápidos, asumiendo que no hay contención de recursos cuando varios procesos cache.exe se ejecutan simultáneamente en todos esos núcleos. Como señalé anteriormente, pero merece la pena repetirlo, cada versión de Caché presenta mejoras en el uso de los recursos de la CPU, por lo que actualizar las aplicaciones a las últimas versiones de Caché puede beneficiarse de más núcleos disponibles. Otra consideración importante es maximizar los núcleos por servidor cuando se utiliza la virtualización. Es posible que las máquinas virtuales individuales no tengan un elevado número de núcleos, pero en conjunto hay que encontrar un equilibrio entre el número de servidores necesarios para la disponibilidad y minimizar el número de hosts para la administración y la consideración de los costes mediante el aumento del número de núcleos. ## Virtualización de VMware y CPU La virtualización de VMware funciona bien para Caché cuando se utiliza con los componentes de almacenamiento y del servidor actuales. Al seguir las mismas reglas que la planificación de la capacidad física, no hay un impacto significativo en el rendimiento usando la virtualización de VMware en el almacenamiento, la red y los servidores configurados correctamente. La compatibilidad con la virtulaización es mucho mejor en procesadores Intel Xeon posteriores, en concreto solo deberías considerar la virtualización en Intel Xeon 5500 (Nehalem) y versiones posteriores, es decir: Intel Xeon 5500, 5600, 7500, serie E7 y serie E5. --- # Ejemplo: Actualización de hardware, cómo calcular los requerimientos mínimos de CPU Poniendo en práctica los consejos y procedimientos anteriores, nuestro ejemplo es una actualización de servidor de una carga de trabajo que se ejecuta en Dell PowerEdge R710 con 8 núcleos (dos procesadores de 4 núcleos Xeon 5570). Al hacer un gráfico del uso actual de la CPU en el servidor de producción primario en el cliente, vemos que el servidor está alcanzando un máximo de menos del 80% durante la parte más activa del día. La fila de ejecución no está bajo presión. La Entrada/Salida y la aplicación también funcionan bien, por lo que no hay cuellos de botella que superen supriman la CPU.  > **Regla general**: Comienza por dimensionar los sistemas para un uso máximo del 80% de la CPU al final de la vida útil del hardware, teniendo en cuenta el crecimiento esperado (por ejemplo, un aumento de usuarios/transacciones). Esto permite crecimientos inesperados, eventos inusuales o picos inesperados de actividad. Para que los cálculos sean más claros, vamos a suponer que no se espera un crecimiento del rendimiento durante la vida del nuevo hardware: El escalado por núcleo se puede calcular como: (251/8) (1030/24) o un aumento del 26% en el rendimiento por núcleo. El 80% de la CPU con **8 núcleos** en el servidor anterior equivale aproximadamente al 80% de la CPU con **6 núcleos** en los nuevos procesadores E5-2680 V3. Así, el mismo número de transacciones podría estar soportado por seis núcleos. El cliente tiene varias opciones, puede comprar nuevos servidores hardware dedicados que cumplan el requisito mínimo de seis núcleos de CPU E5-2680 V3 o su equivalente, o avanzar con sus planes para virtualizar su carga de trabajo de producción en VMware. Virtualizar tiene sentido para aprovechar las ventajas de la consolidación, flexibilidad y alta disponibilidad de los servidores. Dado que hemos calculado los requisitos de la CPU, el cliente puede avanzar con confianza para ajustar correctamente el tamaño de las máquinas virtuales de producción en VMware. Como nota al margen, comprar servidores actuales con una baja cantidad de núcleos es una opción cara o de difícil acceso, lo cual hace que la virtualización sea una opción aún más atractiva. Virtualizar también ofrece ventajas si se espera un crecimiento significativo. Los requisitos de la CPU se pueden calcular en función del crecimiento en los primeros años. Si se realiza una monitorización constante, una estrategia válida es añadir recursos adicionales solo cuando sea necesario y antes de necesitarlos. --- # Consideraciones sobre la CPU y la virtualización Como hemos visto, los sistemas de producción en Caché son dimensionados en función de los análisis de rendimiento y las medidas realizadas en los clientes. También es válido dimensionar los requerimientos de la CPU virtual (vCPU) de VMware a partir de la monitorización de los equipos de hardware dedicado. La virtualización por medio del almacenamiento compartido añade muy poca sobrecarga a la CPU comparado con el hardware dedicado**. Para los sistemas de producción, utiliza una estrategia de ajustar el tamaño inicial del sistema igual que los núcleos de CPU de hardware dedicado. __**Nota:__ Para implementaciones de VMware VSAN debes añadir un búfer de la CPU a nivel host del 10% para el procesamiento de vSAN. Se deben considerar las siguientes reglas para asignar CPUs virtuales: __Recomendación:__ No asignes más CPUs virtuales de las necesarias para lograr un rendimiento adecuado. - Aunque se puede asignar un gran número de CPUs virtuales a una máquina virtual, la práctica recomendada es no asignar más de las necesarias, ya que puede haber una sobrecarga de rendimiento (normalmente baja) para administrar las CPUs virtuales no utilizadas. La clave es monitorizar tus sistemas frecuentemente para asegurarse de que las máquinas virtuales tengan el tamaño adecuado. __Recomendación:__ Los sistemas de producción, especialmente los servidores de bases de datos, inicialmente ajustan el tamaño para 1 CPU física = 1 CPU virtual. - Se espera que los servidores de producción, especialmente los de bases de datos, tengan un alto nivel de uso. Si necesitas seis núcleos físicos, ajusta el tamaño para seis núcleos virtuales. Consulta también la nota sobre el Hyper Treading que se encuentra más abajo. ## Sobresuscripción La sobresuscripción se refiere a varios métodos por los cuales más recursos de los disponibles en el servidor físico se pueden asignar hacia los servidores virtuales que son compatibles con ese host. En general, es posible consolidar los servidores por medio de la sobresuscripción de recursos de procesamiento, memoria y almacenamiento en máquinas virtuales. La sobresuscripción del servidor sigue siendo posible cuando se ejecutan bases de datos de producción en Caché; sin embargo, para ajustar el tamaño inicial de los sistemas de _producción_ se asume que la CPU virtual tiene dedicación completa del núcleo. Por ejemplo, si tienes un servidor E5-2680 V3 de 24 núcleos (2 de 12 núcleos), ajusta el tamaño para una capacidad total de hasta 24 CPUs virtuales, sabiendo que podría haber espacio libre disponible para consolidación. En esta configuración se asume que el Hyper Threading está habilitado a nivel del servidor. Una vez que hayas pasado tiempo monitorizando la aplicación, el sistema operativo y el rendimiento de VMware durante las horas pico de procesamiento, puedes decidir si es posible una mayor consolidación. Si estás mezclando máquinas virtuales que no son de producción, una regla general que uso a menudo para ajustar el tamaño del sistema y calcular los núcleos de CPU totales es ajustar _inicialmente_ las CPUs que no son de producción en 2:1 físicas a virtuales. Sin embargo, esta es definitivamente un área en la que los resultados podrían variar y se deberá monitorizar el sistema para ayudar a planificar la capacidad. Si tienes dudas o no tienes experiencia, puedes separar las máquinas virtuales de producción de las que no lo son a nivel de servidor o por medio de la configuración de vSphere hasta comprender las cargas de trabajo. VMware vRealize Operations y otras herramientas de terceros ofrecen la posibilidad de monitorizar los sistemas a lo largo del tiempo, y sugerir la consolidación o alertar de que se requieren más recursos para las máquinas virtuales. En un artículo posterior hablaré sobre otras herramientas de monitorización disponibles. La conclusión es que, en el ejemplo de nuestros clientes, pueden estar seguros de que su máquina virtual de producción con 6 CPUs virtuales funcionará bien; siempre y cuando los otros "grupos alimenticios" principales, como las Entradas/Salidas y el almacenamiento, tengan capacidad suficiente ;-D ## Hyper Threading y planificación de la capacidad Un buen punto de partida para ajustar el tamaño de las máquinas virtuales basado en reglas conocidas para los servidores físicos es calcular los requisitos de la CPU del servidor físico, con el objetivo por procesador con Hyper Threading activado, y después simplemente hacer la traducción: > una CPU física (incluido el Hyper Threading) = una CPU virtual (incluido el Hyper Threading). Un concepto erróneo común es que el Hyper Threading duplica de alguna manera la capacidad de la CPU virtual. Esto NO es cierto para los servidores físicos o para las CPUs virtuales lógicas. Como regla general, el Hyper Threading en un servidor de hardware dedicado puede ofrecer un 30% de capacidad de rendimiento adicional comparado con el mismo servidor sin Hyper Threading. La misma regla del 30% se aplica a los servidores virtualizados. ## Licencias y CPUs virtuales En vSphere, se puede configurar una máquina virtual con una cierta cantidad de ranuras o núcleos. Por ejemplo, si tienes una máquina virtual con doble procesador, se puede configurar para que tenga dos ranuras de CPU, o una única ranura con dos núcleos de CPU. Desde el punto de vista de la ejecución no hay mucha diferencia porque el hipervisor decidirá en última instancia si la máquina virtual se ejecuta en una o dos ranuras físicas. Sin embargo, especificar que la máquina virtual de doble CPU en realidad tiene dos núcleos en lugar de dos ranuras podría marcar una diferencia para las licencias de software que no son de Caché. --- # Resumen En este artículo describí cómo comparar procesadores entre proveedores, servidores o modelos usando los resultados del análisis de rendimiento SPECint. También cómo planificar la capacidad y elegir los procesadores en función del rendimiento y la arquitectura, tanto si se utiliza la virtualización como si no. Estos son temas complejos, en los que es fácil irse por las ramas… Por eso, al igual que en mis otras publicaciones, no dejes de hacer comentarios o preguntas si deseas profundizar en algún tema relacionado. — # EJEMPLO: Búsqueda de resultados de SPECint_rate2006. #### En la siguiente imagen se muestra la selección de los resultados de SPECint_rate2006.  ---- #### Utiliza la pantalla de búsqueda para reducir resultados. #### Ten en cuenta que también se pueden descargar todos los registros a un archivo .csv de aproximadamente 20 MB para su procesamiento local, por ejemplo con Excel. #### Los resultados de la búsqueda muestran el Dell R730.   --- #### Selecciona HTML para dar el resultado completo del análisis de rendimiento.  --- Puedes ver los siguientes resultados para servidores con los procesadores de nuestro ejemplo. Dell PowerEdge R710 con 2.93 GHz: 8 núcleos, 2 chips, 4 núcleos/chips, 2 hilos/núcleos con Xeon 5570: __SPECint_rate_base2006 = 251__ PowerEdge R730 (Intel Xeon E5-2680 v3, 2.50 GHz) de 24 núcleos, 2 chips, 12 núcleos/chips, 2 hilos/núcleos con Xeon E5-2680 v3: __SPECint_rate_base2006 = 1030__

InterSystems API Manager (IAM) es una nueva función de InterSystems IRIS que permite monitorizar, controlar y dirigir el tráfico hacia y desde las APIs web dentro de su infraestructura de TI. Si te perdiste el anuncio de su lanzamiento, puedes leerlo [aquí](https://es.community.intersystems.com/post/lanzamiento-de-intersystems-api-manager). También puedes consultar este otro [artículo](https://es.community.intersystems.com/post/presentaci%C3%B3n-de-intersystems-api-manager). En esta publicación, utilizaremos InterSystems API Manager para balancear la carga de una API. En nuestro caso, tenemos 2 instancias de InterSystems IRIS con `/api/atelier` API REST que queremos publicar para nuestros clientes. Hay muchas razones diferentes por las que podríamos querer hacer eso, como: * Equilibrio de carga para distribuir la carga de trabajo entre los servidores * Implementación azul-verde: tenemos dos servidores, uno "prod", otro "dev" y es posible que queramos cambiar entre ellos * Implementación de Canary: podríamos publicar la nueva versión solo en un servidor y mover el 1% de los clientes allí * Configuración de alta disponibilidad * etc. Aun así, los pasos que debemos dar son bastante similares. ### **Requisitos previos** * 2 instancias de InterSystems IRIS * Instancia de InterSystems API Manager   ### **Vamos** Esto es lo que tenemos que hacer: **1. Crear un upstream.** El upstream representa un *hostname* virtual y se puede utilizar para equilibrar en varios servicios (objetivos) la carga de las solicitudes que entran. Por ejemplo, un *upstream* llamado `service.v1.xyz` recibiría solicitudes para un Servicio cuyo servidor es `service.v1.xyz`. Las solicitudes de este Servicio se dirigirían a los objetivos definidos en el *upstream*. Un *upstream* también incluye un verificador de estado, que puede habilitar y deshabilitar objetivos en función de su capacidad o incapacidad para atender solicitudes. Para empezar: * Abre el Portal de Administración de IAM * Ve a los espacios de trabajo (*workspaces*) * Elige un espacio de trabajo * Abre Upstreams * Haz clic en el botón "New Upstream" Después de hacer clic en el botón "New Upstream", verás un formulario en el que podrás introducir información básica sobre el *upstream* (hay muchas más propiedades): Introduce _name_ - es un *hostname* virtual que nuestros servicios podrían utilizar. No está relacionado con los historiales del DNS. Recomiendo establecerlo en un valor que no exista para evitar confusiones. Si quieres leer sobre el resto de propiedades, [puedes consultar la documentación](https://docs.intersystems.com/irislatest/csp/docbook/apimgr/1.0.x/admin-api.html#upstream-object). En la captura de pantalla, puedes ver cómo nombré al nuevo *upstream* como `myupstream`.   **2. Crear objetivos.** Los objetivos son servidores *backend* que ejecutan las solicitudes y envían los resultados al cliente. Ve a *Upstreams* y haz clic en el nombre del *upstream* que acabas de crear (y NO en el botón de actualización): Verás todos los objetivos existentes (ninguno hasta ahora) y el botón "New Target". Haz clic: Y en el nuevo formulario define un objetivo. Solo hay dos parámetros disponibles: * target - host y puerto del servidor backend * weight - prioridad relativa que se le da a este servidor (a más weight- más solicitudes se envían a este objetivo) Yo he añadido dos objetivos:   **3. Crear un servicio.** Ahora que tenemos nuestro *upstream*, necesitamos enviarle solicitudes.  Para ello, utilizamos un Servicio. Las entidades de Servicio, como su nombre indica, son abstracciones de cada uno de tus servicios de *upstream*. Ejemplos de Servicios serían un microservicio de transformación de datos, una API de facturación, etc. Vamos a crear un servicio dirigido a nuestra instancia de IRIS. Ve a Servicios y haz clic en el botón "New Service": Establece los siguiente valores: | campo | valor | descripción | | --------- | ------------ | ----------------------------------- | | nombre | myservice | el nombre lógico de este servicio | | host | myupstream | nombre del upstream | | path | /api/atelier | ruta raíz que queremos proporcionar | | protocol | http | los protocolos que queremos admitir |   Mantén los valores predeterminados para todo lo demás (incluyendo el puerto: 80). Después de crear el servicio, lo verás en una lista de servicios. Copia el ID del servicio en algún sitio, vamos a necesitar eso más tarde.   **4. Crear una ruta.** Las rutas definen las reglas para hacer coincidir las solicitudes de los clientes. Cada Ruta está asociada a un Servicio, y un Servicio puede tener varias Rutas asociadas con él. Cada solicitud que coincida con una Ruta determinada se redirigirá a su Servicio asociado. La combinación de Rutas y Servicios (y la separación de problemas entre ellos) ofrece un potente mecanismo de enrutamiento con el que es posible definir puntos de entrada detallados en IAM que conducen a diferentes servicios *upstream* de tu infraestructura. Ahora vamos a crear una ruta. Ve a Rutas y haz clic en el botón "New Route". Establece los valores en el formulario de creación de rutas: campo valor descripción path /api/atelier ruta raíz que queremos proporcionar protocol http los protocolos que queremos admitir service.id guid from 3 valor id del servicio (guid del paso anterior)   ¡Y terminamos! Envía una solicitud a `http://localhost:8000/api/atelier/` (con una barra al final) y será presentada por uno de nuestros dos backends.   ### **Conclusión** IAM ofrece una infraestructura de administración de API altamente personalizable, lo que permite que los desarrolladores y administradores tomen el control de sus API.   ### **Enlaces** * [Documentación](https://docs.intersystems.com/irislatest/csp/docbook/apimgr/index.html) * [Anuncio de IAM](https://es.community.intersystems.com/post/lanzamiento-de-intersystems-api-manager)  * [Presentación de IAM](https://es.community.intersystems.com/post/presentaci%C3%B3n-de-intersystems-api-manager)   ### **Pregunta** ¿Qué función quieres ver configurada con IAM?

**Este artículo es una continuación de esta publicación.** El objetivo de este artículo es explicar cómo funciona el menú de interoperabilidad para la integración del sistema.  La parte izquierda de la figura representa la ventana para aceptar información enviada desde sistemas externos. Hay varias maneras de recibir información, como monitorizar el directorio especificado a intervalos regulares para leer archivos, consultar periódicamente la base de datos, esperar a que se introduzcan datos, o llamar directamente y que se pasen desde aplicaciones en otros sistemas. En el mecanismo de integración del sistema creado en el menú Interoperabilidad de IRIS, la información recibida se almacena en un objeto llamado **mensaje**. El **mensaje** se envía al componente responsable de su procesamiento posterior. Se puede crear un **mensaje** utilizando toda la información recibida o solo una parte de ella. Supón que deseas enviar la información contenida en el **mensaje** a un sistema externo. En ese caso, es necesario que envíes el mensaje al componente responsable de solicitar a la red externa que lo procese (la parte derecha de la figura). El componente que recibe el **mensaje** solicitará al sistema externo que lo procese. Además, supón que un **mensaje** requiere que una persona lo revise, conversión de datos o adjuntar datos. En ese caso, el **mensaje** se envía al componente situado en el centro del diagrama (BPM), que es el encargado de coordinar el flujo del proceso. Los **mensajes** se utilizan para enviar y recibir datos entre cada componente. Cuando se envía o se recibe un **mensaje**, este se almacena automáticamente en la base de datos. Como los **mensajes** se almacenan en la base de datos, se puede revisar la diferencia entre antes y después de la conversión de datos. Revisa el **mensaje** que fue la fuente de un problema durante una operación o vuelva a empezar (reenvío) desde la mitad del proceso. Verifica el estado utilizando **mensajes** en cada etapa de desarrollo, prueba y operación. Una imagen sencilla de la integración del sistema se dividiría en tres componentes (*business services*, *business processes* y *business operations*), como se muestra en la siguiente figura. También hay una definición llamada "**producción**" que almacena información sobre los componentes que se van a utilizar (por ejemplo, la información de la conexión).  La función de cada componente es la siguiente: ***Business services*** Responsables de recibir información de fuentes externas, crear **mensajes** y enviar **mensajes** a otros componentes. ***Business processes*** Esta función se activa cuando se recibe un **mensaje**. Es responsable de coordinar el proceso (llamando a los componentes en el orden definido, esperando respuestas, esperando los resultados de la revisión humana, etc.). ***Business operations*** Esta función se activa cuando se recibe un **mensaje**. Tiene la función de solicitar al sistema externo que procese el mensaje. Los **mensajes** se utilizan para enviar y recibir datos entre componentes. Los componentes que son distintos de los *business services* inician el procesamiento cuando reciben un **mensaje**. La pregunta es: ¿cuál es el propósito de crear y utilizar este **mensaje**? Los **mensajes** se crean mediante la recuperación de la información que quieres transmitir al sistema externo a partir de los datos introducidos en el business service. Dado que no todos los sistemas externos conectados a IRIS utilizan el mismo tipo de formato de datos para transmitir, y el contenido a transmitir varía, la producción puede definir libremente las clases de mensaje de acuerdo con la información. Hay dos tipos de **mensajes**: solicitudes (= mensaje de solicitud) y respuesta (= mensaje de respuesta). El **mensaje** que desencadena la activación del componente se denomina solicitud (= mensaje de solicitud), y el **mensaje** al que responde el componente después de su procesamiento se denomina respuesta (= mensaje de respuesta). Estos **mensajes** se diseñarán mientras se considera el proceso de transmisión. En los siguientes artículos, utilizaremos un caso de estudio para describir la creación de producciones, **mensajes** y componentes.

¡Hola desarrolladores! Os traemos el segundo tutorial grabado por @David.Reche, y disponible en el canal de YouTube de la Comunidad de Desarrolladores en español: Contenedor de InterSystems IRIS con Docker Compose. En este segundo tutorial de seis minutos, David nos mostrará cómo trabajar con Docker Compose. ⏯ Tutorial 2: Contenedor de InterSystems IRIS con Docker Compose ¡Esperamos que os resulte útil! ¡Y recordad que podéis suscribiros al canal de YouTube de la Comunidad de Desarrolladores en español, para manteneros formados e informados!

¡Hola desarrolladores! Hoy os traemos un breve tutorial, grabado por @David.Reche, y disponible en el canal de YouTube de la Comunidad de Desarrolladores en español: Cómo arrancar un contenedor de InterSystems IRIS en Docker. Es el primer vídeo de una serie de tutoriales grabados por David, en los que explica los primeros pasos para empezar a trabajar con InterSystems IRIS Community Edition. Iremos publicando los tutoriales durante los próximos días. ⏯ Tutorial 1: Cómo arrancar un contenedor de InterSystems IRIS en Docker ¡Esperamos que os resulte útil! ¡Y recordad que podéis suscribiros al canal de YouTube de la Comunidad de Desarrolladores en español, para manteneros formados e informados!

¡Hola desarrolladores! Os traemos el quinto tutorial grabado por @David Reche, y disponible en el canal de YouTube de la Comunidad de Desarrolladores en español: Cómo trabajar con InterSystems IRIS y Visual Studio Code. En este tutorial de siete minutos, David nos mostrará cómo trabajar con InterSystems IRIS y ObjectScript, para lo que hay que instalar y configurar InterSystems ObjectScript, una extensión de VS Code. ⏯ Tutorial 5: Cómo trabajar con InterSystems IRIS y VS Code ¡Esperamos que os resulte útil! ¡Y recordad que podéis suscribiros al canal de YouTube de la Comunidad de Desarrolladores en español, para manteneros formados e informados!

¡Hola amigos! A veces necesitamos importar datos a InterSystems IRIS desde archivos de tipo CSV. Esto puede hacerse, por ejemplo, mediante la herramienta [csvgen](https://openexchange.intersystems.com/package/csvgen), que genera una clase e importa todos los datos a ella. Pero, ¿qué pasa si tienes tu propia clase y quieres importar datos desde un archivo CSV a una tabla que ya existe previamente? Hay varias formas de hacerlo, ¡pero puedes utilizar csvgen (o [csvgen-ui](https://openexchange.intersystems.com/package/csvgen-ui)) otra vez! Preparé un ejemplo y estoy encantado de compartirlo con todos. ¡Vamos allá! El concepto es el siguiente: Tengo la clase A y quiero los datos del archivo.csv, ya que este archivo contiene una columna que necesito para mi clase. Los pasos son los siguientes: 1. Crear la clase B utilizando csvgen 2. Efectuar una actualización en SQL para añadir los datos de la clase B en la clase A 3. Eliminar la clase B Para explicar el concepto, creé una [demostración sencilla del proyecto](https://github.com/evshvarov/csv-sql-update). El proyecto importa el [conjunto de datos Countries](https://openexchange.intersystems.com/package/iris-dataset-countries), que contiene la clase dc_data.Country con información variada sobre los países, incluido el GNP (PIB en español). ClassMethod ImportCSV() As %Status { set sc = ##class(community.csvgen).GenerateFromURL("https://raw.githubusercontent.com/evshvarov/test-ipad/master/gnp.csv",",","dc.data.GNP") Return sc } Pero los datos del GNP están desactualizados y los más recientes se encuentran en [este CSV.](https://github.com/evshvarov/csv-sql-update/blob/master/gnp.csv) Este es el método que muestra el GNP, por ejemplo, para Angola: ClassMethod ShowGNP() As %Status { Set sc = $$$OK &sql( SELECT TOP 1 name,gnp into :name,:gnp from dc_data.Country ) if SQLCODE < 0 throw ##class(%Exception.SQL).CreateFromSQLCODE(SQLCODE,"Show Country GNP") write "Country ",name," gnp=",gnp,! Return sc } Entonces importo el CSV en una clase generada con una línea: ClassMethod ImportCSV() As %Status { set sc = ##class(community.csvgen).GenerateFromURL("https://raw.githubusercontent.com/evshvarov/test-ipad/master/gnp.csv",",","dc.data.GNP") Return sc } y con la segunda línea realizo una consulta en SQL que importa los datos actualizados del GNP a mi clase dc_data.Country. ClassMethod UpdateGNP() As %Status { Set sc = $$$OK &sql( UPDATE dc_data.Country SET Country.gnp=GNP."2020" FROM dc_data.Country Country INNER JOIN dc_data.GNP GNP On Country.name=GNP.CountryName ) if SQLCODE < 0 throw ##class(%Exception.SQL).CreateFromSQLCODE(SQLCODE,"Importing data") w "Changes to GNP are made from dc.data.GNP",! Return sc } Y luego, elimino la clase generada (con todos sus datos) porque ya no la necesito. ClassMethod DropGNP() As %Status { Set sc = $$$OK &sql( DROP TABLE dc_data.GNP ) if SQLCODE < 0 throw ##class(%Exception.SQL).CreateFromSQLCODE(SQLCODE,"Drop csv table") write "dc.data.DNP class is deleted.",! Return sc } Y este es el método que hace todo al mismo tiempo: ClassMethod RunAll() As %Status { Set sc = $$$OK zw ..ImportDataset() zw ..ShowGNP() zw ..ImportCSV() zw ..UpdateGNP() zw ..ShowGNP() zw ..DropGNP() Return sc } Por supuesto, esta solo es una de las formas de solucionar el problema, pero espero que sea útil. ¡Me encantaría recibir vuestros comentarios!  

¡Hola desarrolladores! Gracias a todos los que habéis empezado el desarrollo con InterSystems IRIS desde la plantilla de desarrollo básico! Recientemente, gracias a las contribuciones de @Dmitry.Maslennikov, he actualizado el Dockerfile para hacer el desarrollo más sencillo, las imágenes más ligeras y el proceso de construcción más rápido. Y también parece más bonito ;) Esto es lo que ha cambiado: Vamos a repasar los cambios: 1. Las líneas 11-15 han sido sustituidas por una única línea 7, que define el WORKDIR. WORKDIR /home/irisowner/irisbuild De hecho, si WORKDIR señala a una carpeta de inicio del usuario que ejecuta iris, no hace falta realizar ajustes de seguridad. Por supuesto, debería cambiar la línea en iris.script para cargar el módulo zpm desde otra carpeta workdir 2. Las líneas 17-21 eran comandos COPY que yo solía usar para copiar diferentes archivos desde la carpeta origen del repo a una imagen para usarla para iris en el entorno. Ahora todas esas líneas han sido sustituidas por una línea RUN --mount=type=bind,src=.,dst=. \ Esta sintaxis usa la funcionalidad buildkit de Docker que permite montar los archivos que necesitas en la imagen, sin copiarlos realmente. Esto ahorra espacio y acelera el proceso de construcción de la imagen. Así que con todo esto puedes olvidarte de los comandos COPY: todo lo de la carpeta repo se montará y estará disponible en un WORKDIR durante la fase de construcción. Bonito, ¿eh? Asegúrate de tener esta opción habilitada en tu Docker: 3. Lo que se ha añadido es la línea con parámetro TEST: ARG TESTS=0 Si TESTS=1 hace que Dockerfile llame test unitarios para el módulo ZPM que desarrollas en el proyecto. Esto se controla con la siguiente línea: ([ $TESTS -eq 0 ] || iris session iris "##class(%ZPM.PackageManager).Shell(\"test $MODULE -v -only\",1,1)") && \ Este parámetro TESTS también ayuda a realizar test unitarios automáticamente durante el CI. Esto merece un tema de discusión adicional y continuaré con ello en el próximo artículo. O puedes mirarlo en el código de Dmitry si no puedes esperar :D Espero que os haya gustado. Y cualquier comentario, duda o pull request es bienvenido. Happy coding!

¡Hola desarrolladores! Ya podéis votar las mejores aplicaciones del 2º Gran Premio de Programación de InterSystems! 🔥 Vosotros decidís: Podéis votar aquí 🔥 ¿Cómo se vota? Nominación de los expertos: El experimentado jurado de InterSystems elegirá las mejores apps que ganarán en la categoría "Nominación de los expertos". Estos son los miembros del jurado: ⭐️ @Alexander.Woodhead, Technical Specialist⭐️ @Steven.LeBlanc, Product Specialist⭐️ @Alexander.Koblov, Senior Support Specialist⭐️ @Daniel.Kutac, Senior Sales Engineer⭐️ @Eduard.Lebedyuk, Senior Cloud Engineer⭐️ @Steve.Pisani, Senior Solution Architect⭐️ @Timothy.Leavitt, Development Manager⭐️ @Thomas.Dyar, Product Specialist⭐️ @Andreas.Dieckow, Product Manager⭐️ @Benjamin.DeBoe, Product Manager⭐️ @Carmen.Logue, Product Manager⭐️ @Luca.Ravazzolo, Product Manager⭐️ @Stefan.Wittmann, Product Manager⭐️ @Raj.Singh5479, Product Manager⭐️ @Robert.Kuszewski, Product Manager⭐️ @Jeffrey.Fried, Director of Product Management⭐️ @Dean.Andrews2971, Head of Developer Relations ⭐️ @Evgeny.Shvarov, Developer Ecosystem Manager Nominación de la Comunidad: Para cada miembro de la Comunidad, la puntuación más alta se elige de dos categorías: Condiciones Puesto 1º 2º 3º Si has publicado un artículo en la CD y has subido una app a Open Exchange (OEX) 9 6 3 Si has publicado al menos un artículo en la CD o has subido una app a OEX 6 4 2 Si has hecho alguna contribución válida a la CD (publicar un comentario/pregunta, etc.) 3 2 1 Nivel Puesto 1º 2º 3º Nivel VIP en Global Masters o Product Manager de InterSystems Corporation 15 10 5 Nivel Ambassador en Global Masters 12 8 4 Nivel Experto en Global Masters o Moderador de la CD 9 6 3 Nivel Specialist en Global Masters 6 4 2 Nivel Advocate en Global Masters o Empleado de InterSystems Corporation 3 2 1 Número de votos secreto El número de votos de cada app estará oculto. Y una vez al día publicaremos la clasificación en los comentarios a esta publicación. El orden en el que se mostrarán los proyectos en la página del concurso será el orden de presentación de los proyectos: las aplicaciones presentadas antes aparecerán primero en la lista. P. D. Podéis suscribiros a la publicación original en inglés haciendo clic en el icono de la campana para ser notificados cuando haya nuevos comentarios. Requisitos para poder votar: Registrarse en Open Exchange – se puede hacer con las credenciales de acceso a la Comunidad. Haber participado de alguna manera en la Comunidad de Desarrolladores (haciendo una pregunta, respondiendo a alguien, escribiendo un artículo, subiendo aplicaciones a Open Exchange, etc.) – entonces verás el botón "Vote" disponible. En esta publicación puedes conocer todas las opciones para participar en la Comunidad de Desarrolladores. ¡Si en algún momento quieres cambiar el voto, puedes cancelar el que hayas dado y dárselo a otra aplicación! ¡A votar! Nota: Los participantes en el concurso pueden corregir errores ("bugs") e introducir mejoras en sus aplicaciones durante esta semana. Para no perderte los cambios, suscríbete a los avisos sobre nuevas actualizaciones!

¡Hola Comunidad! Como sabéis, ya está disponible la versión 2022.2 de InterSystems IRIS, IRIS for Health, HealthShare Health Connect e InterSystems IRIS Studio! Y para comentar las nuevas funcionalidades y mejoras de la nueva versión, queremos invitaros al webinar: What’s New in InterSystems IRIS 2022.2. Nota.- el webinar será en inglés. Durante el webinar, destacaremos algunas de las nuevas funcionalidades de la versión 2022.2 de InterSystems IRIS® e InterSystems IRIS for Health™, como: Columnar storage - versión beta Nuevo editor de reglas Mejoras en SQL Soporte para nuevas plataformas Conectores para almacenamiento en cloud de Microsoft Azure y Google Cloud Ponentes:🗣 @Robert.Kuszewski, Product Manager, Developer Experience🗣 @Benjamin.DeBoe, Product Manager Esta vez, hemos decidido realizar el webinar tres días diferentes y a tres horas distintas, para que todo el mundo pueda escoger el horario que más le convenga. Las opciones son: 📅 Día: Martes 15 de noviembre de 2022⏱ Hora: 3:00 AM (CET)🔗 Registro aquí 📅 Día: Jueves 17 de noviembre de 2022⏱ Hora: 19:00 PM (CET)🔗 Registro aquí 📅 Día: Martes 22 de noviembre de 2022⏱ Hora: 11:00 AM (CET)🔗 Registro aquí ¡Nos vemos pronto!