Si estás ejecutando IRIS en una configuración en mirror para alta disponibilidad (HA) en Azure, la cuestión de proporcionar una Mirror VIP (Virtual IP) es relevante. La Virtual IP ofrece una forma para que los sistemas interactuen con IRIS utilizando una dirección IP. Incluso cuando ocurre un failover, los otros sistemas pueden reconectarse a la misma dirección IP y continuar trabajando.

El problema principal, cuando se despliega en Azure, es que una IRIS VIP tiene el requerimiento de que IRIS sea esencialmente un admin de red, según se indica en la documentación.

Para tener HA, los miembros en mirror de IRIS deben ser desplegados en diferentes zonas de disponibilidad (availability zones o AZ) en una subred (lo que es posible en Azure ya que las subredes pueden abarcar varias zonas). Una de las soluciones puede ser utilizar balanceadores de carga pero, por supuesto, suponen un coste extra, y también necesitarás administrarlos.

En este artículo, quiero proporcionar un modo de configurar una Mirror VIP sin la utilización de balanceadores de carga que se sugiere en la mayoría de las propouestas de arquitectruas de referencia para Azure.

Arquitectura

Tenemos una subred activa entre 2 zonas de disponibilidad (simplifico aquí - por supuesto, probablemente tendrás subredes públicas, arbitro en otra AZ, y así sucesivamente, pero esto es un ejemplo de lo mínimo imprescindible para demostrar esta propuesta). El CIDR de la subred es 10.0.0.0/24, lo que significa que las IPs que asigna van de la 10.0.0.1 a 10.0.0.255. Como Azure reserva las primeras 4 direcciones y la última dirección, podemos usar de la 10.0.0.4 a la 10.0.0.254.

Implementaremos ambos, una VIP pública y una privada al mismo tiempo. Si quieres, puedes implementar sólo la VIP privada.

Idea

Las máquinas virtuales en Azure tienen Interfaces de Red. Estos Interfaces de Red tienen Configuraciones IP. La configuración IP es una combinación de IPs Publica y Privada, y se enruta automáticamente a la máquina virtual asociada con la Interfaz de Red. Así que no hay necesidad de actualizar las rutas. Lo que haremos es, durante un evento de failover, borrar la configuración VIP IP del antiguo primario y crearla para un nuevo primario. Todas las operaciones para hacer eso llevan sólo unos 5-20 segundos por VIP Privada, y de 5 segundos a 1 minuto para una combinación de VIP IP Pública/Privada.

Implementando la VIP

1. Asignar IP Externa para usas como una VIP pública. Salta este paso si sólo quieres una VIP Privada. Si asignas la VIP, debe residir en el mismo grupo de recursos y en la misma región y estar en todas las zonas con primario y backup. Necesitarás un nombre de IP Externa.
2. Decide el valor de la VIP Privada. Yo utilizaré la última disponible: 10.0.0.254.
3. En cada VM (Virtual Machine), asigna la dirección de IP de la VIP Privada al interfaz de red eth0:1.

cat << EOFVIP >> /etc/sysconfig/network-scripts/ifcfg-eth0:1
          DEVICE=eth0:1
          ONPARENT=on
          IPADDR=10.0.0.254
          PREFIX=32
          EOFVIP
sudo chmod -x /etc/sysconfig/network-scripts/ifcfg-eth0:1
sudo ifconfig eth0:1 up

Si sólo quieres probar, ejecuta: (pero no sobrevivirá a un reinicio de sistema)

sudo ifconfig eth0:1 10.0.0.254

Dependiendo del SO puede que necesites ejecutar:

ifconfig eth0:1
systemctl restart network

4. Para cada VM, habilita Identidad asignada al Sistema o Usuario.
5. Para cada identidad, asigna los permisos para modificar los Interfaces de Red. Para hacer eso crea un rol a medida, el permiso mínimo a establecer en ese caso sería:

{
  "roleName": "custom_nic_write",
  "description": "IRIS Role to assign VIP",
  "assignableScopes": [
    "/subscriptions/{subscriptionid}/resourceGroups/{resourcegroupid}/providers/Microsoft.Network/networkInterfaces/{nicid_primary}",
    "/subscriptions/{subscriptionid}/resourceGroups/{resourcegroupid}/providers/Microsoft.Network/networkInterfaces/{nicid_backup}"
  ],
  "permissions": [
    {
      "actions": [
        "Microsoft.Network/networkInterfaces/write",
        "Microsoft.Network/networkInterfaces/read"
      ],
      "notActions": [],
      "dataActions": [],
      "notDataActions": []
    }
  ]
}

Para entornos de no-producción podría utilizar un rol de sistema de tipo Network Contributor en el grupo de recursos, pero no está recomendado porque el Network Contributor es un rol muy amplio.

6. Cada interfaz de red en Azure puede tener un conjunto de configuracion de IP. Cuando un miembro actual del mirror se convierte en primario, usaremos un callback de ZMIRROR para borrar una configuración de IP VIP del interfaz de red del otro miembre del miror y crear una configuración de VIP IP que le apunte a él mismo:

Aquí tienes los comandos de Azure CLI para ambos nodos, asumiendo el grupo de recursos rg, la configuración de IP vip, y mi IP Externa my_vip_ip:

az login --identity
az network nic ip-config delete --resource-group rg --name vip --nic-name mirrorb280_z2
az network nic ip-config create --resource-group rg --name vip --nic-name mirrora290_z1 --private-ip-address 10.0.0.254 --public-ip-address my_vip_ip

y:

az login --identity
az network nic ip-config delete --resource-group rg --name vip --nic-name mirrora290_z1
az network nic ip-config create --resource-group rg --name vip --nic-name mirrorb280_z2 --private-ip-address 10.0.0.254 --public-ip-address my_vip_ip

Y el mismo código en una rutina ZMIRROR:

ROUTINE ZMIRROR

NotifyBecomePrimary() PUBLIC {
    #include %occMessages
    set rg = "rg"
    set config = "vip"
    set privateVIP = "10.0.0.254"
    set publicVIP = "my_vip_ip"

    set nic = "mirrora290_z1"
    set otherNIC = "mirrorb280_z2"
    if ##class(SYS.Mirror).DefaultSystemName() [ "MIRRORB" {
        // we are on mirrorb node, swap
        set $lb(nic, otherNIC)=$lb(otherNIC, nic)
    }

    set rc1 = $zf(-100, "/SHELL", "export", "AZURE_CONFIG_DIR=/tmp", "&&", "az", "login", "--identity")
    set rc2 = $zf(-100, "/SHELL", "export", "AZURE_CONFIG_DIR=/tmp", "&&", "az", "network", "nic", "ip-config", "delete", "--resource-group", rg, "--name", config, "--nic-name", otherNIC)
    set rc3 = $zf(-100, "/SHELL", "export", "AZURE_CONFIG_DIR=/tmp", "&&", "az", "network", "nic", "ip-config", "create", "--resource-group", rg, "--name", config, "--nic-name",      nic,  "--private-ip-address", privateVIP, "--public-ip-address", publicVIP)
    quit 1
}

La rutina es la misma para ambos miembros del mirror, nosotros simplemente intercambiamos los nombre de NIC basandonos en el nombre del miembre de mirror actual. Puede que no tengas que hacer export AZURE_CONFIG_DIR=/tmp, pero a veces az intenta escribir credenciales en el directorio home de root, lo que podría fallar. En lugar de /tmp, es mejor utilizar el subdirectorio home del usuario IRIS (o puede que ni siquiera necesites ese nombre de variable, dependiendo de tu configuración).

Y, si quieres utilizar Python Embebido, aquí tienes el código de Azure Python SDK:

from azure.identity import DefaultAzureCredential
from azure.mgmt.network import NetworkManagementClient
from azure.mgmt.network.models import NetworkInterface, NetworkInterfaceIPConfiguration, PublicIPAddress

sub_id = "AZURE_SUBSCRIPTION_ID"
client = NetworkManagementClient(credential=DefaultAzureCredential(), subscription_id=sub_id)

resource_group_name = "rg"
nic_name = "mirrora290_z1"
other_nic_name = "mirrorb280_z2"
public_ip_address_name = "my_vip_ip"
private_ip_address = "10.0.0.254"
vip_configuration_name = "vip"


# remove old VIP configuration
nic: NetworkInterface = client.network_interfaces.get(resource_group_name, other_nic_name)
ip_configurations_old_length = len(nic.ip_configurations)
nic.ip_configurations[:] = [ip_configuration for ip_configuration in nic.ip_configurations if
                            ip_configuration.name != vip_configuration_name]

if ip_configurations_old_length != len(nic.ip_configurations):
    poller = client.network_interfaces.begin_create_or_update(
        resource_group_name,
        other_nic_name,
        nic
    )
    nic_info = poller.result()

# add new VIP configuration
nic: NetworkInterface = client.network_interfaces.get(resource_group_name, nic_name)
ip: PublicIPAddress = client.public_ip_addresses.get(resource_group_name, public_ip_address_name)
vip = NetworkInterfaceIPConfiguration(name=vip_configuration_name,
                                      private_ip_address=private_ip_address,
                                      private_ip_allocation_method="Static",
                                      public_ip_address=ip,
                                      subnet=nic.ip_configurations[0].subnet)
nic.ip_configurations.append(vip)

poller = client.network_interfaces.begin_create_or_update(
    resource_group_name,
    nic_name,
    nic
)
nic_info = poller.result()

Arranque inicial

NotifyBecomePrimary se llama también automáticamente cuando el sistema arranca (tras la reconexión del mirror), pero si quieres que tus entornos sin mirror adquieran una VIP del mismo modo, utiliza ZSTART routine:

SYSTEM() PUBLIC {
  if '$SYSTEM.Mirror.IsMember() {
    do NotifyBecomePrimary^ZMIRROR()
  }
  quit 1
}

Conclusión

¡Y ya estaría! Cambiamos la configuración de la IP para apuntar al mirror Primario cuando ocurre un evento NotifyBecomePrimary.

InterSystems ha estado a la vanguardia de la tecnología de bases de datos desde su creación, siendo pionera en innovaciones que superan constantemente a competidores como Oracle, IBM y Microsoft. Al centrarse en un diseño eficiente del núcleo y adoptar un enfoque sin concesiones en el rendimiento de los datos, InterSystems se ha hecho un hueco en las aplicaciones de misión crítica, garantizando fiabilidad, velocidad y escalabilidad.

Una historia de excelencia técnica

Continuando con la serie de análisis de rendimiento, en este artículo voy a mostrar un método para dimensionar los requisitos de memoria compartida para aplicaciones de base de datos que se ejecutan en plataformas de datos de InterSystems, incluyendo los Global y Routine Buffers, gmheap y locksize. También daré algunos consejos de rendimiento que se deberían tener en cuenta al configurar servidores y al virtualizar aplicaciones de Iris. Como siempre, cuando hablo de Iris o Caché , me refiero a toda la plataforma de datos. Este artículo tiene algunos años pero mantiene su esencia, por lo que me referiré a Iris o Caché indistintamente ya que la teoría es exáctamente igual para todos los productos con kernel Caché/Iris. 

InterSystems anuncia que el componente central de InterSystems Supply Chain Orchestrator™, la versión 2023.1 de InterSystems IRIS for Supply Chain, está disponible de manera general (GA).

InterSystems Supply Chain Orchestrator está construido sobre InterSystems IRIS®, nuestra plataforma de datos más completa para entornos on-premise, en nube e híbridos, que posibilita una arquitectura de smart data fabric para hacer más fácil la creación e implementación de aplicaciones de alto rendimiento, que hacen uso de técnicas de machine learning y que permiten conectar silos de aplicaciones y datos. Combina la potencia de InterSystems IRIS con aceleradores y frameworksespecíficos de la cadena de suministro, para ofrecer soluciones optimizadas para la orquestación de la cadena de suministro, percepción de demanda y previsión, compleción de ordenes y reempaquetado de productos que han de moverse rápidamente.

Hemos visto como instalar nuestro EMPI en modo standalone y, parafraseando a Fray Luis de León, como decíamos ayer, procederemos a exponer como realizar una configuración básica, sin demasiadas pretensiones, de nuestro EMPI.

Primeramente deberemos realizar la configuración básica inicial, y para ello deberemos acceder a la opción del menú de Configuración de nuestro Registry.

Desde esta opción tendremos acceso a la tabla de configuración básica de nuestro Registry:

En este menú deberemos incluir los siguientes parámetros y actualizar el valor de los que ya estén presentes:

TOGAF son las siglas de The Open Group Architecture Framework (Esquema de Arquitectura del Open Group). Ofrece un enfoque para planificar, diseñar, implementar, desplegar y controlar proyectos de AE (Arquitectura Empresarial). En otras palabras, ofrece un marco de alto nivel para el desarrollo de software empresarial.

TOGAF ayuda a organizar el proceso de desarrollo a través de un enfoque sistemático dirigido a reducir los errores, mantener los plazos, mantenerse dentro del presupuesto y alinear la TI con las unidades de negocio para producir resultados de calidad.

En un esquema TOGAF se contemplan cuatro dominios: de Negocios, de Aplicaciones, de Datos y de Tecnología.

TOGAF tiene un concepto llamado Building Blocks (Bloques de Construcción). Es cualquier elemento que se puede utilizar, reutilizar y ejecutar para aportar valor y nuevas funciones al negocio.

En la imagen superior, os muestro los principales Bloques de Construcción de IRIS para crear aplicaciones fantásticas.

Para saber más sobre TOGAF y los Bloques de Construcción, podéis consultar https://www.opengroup.org/togaf.

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

Me permito adjuntar un documento que describe un producto que he desarrollado llamado NiPaRobotica Pharmacy. Se trata de una interfaz que desarrollé, que acepta solicitudes para dispensar a farmacias y convierte las líneas de pedido en diálogos de dispensación que se envían a los robots de las farmacias. Implementé la interfaz en 3 farmacias de hospitales, dos de las cuales tenían 6 robots que se organizaron de tal manera que las rampas de dispensación canalizaban los medicamentos hasta los mostradores de los farmacéuticos que atendían en las ventanillas a 1 200 pacientes al día. Los robots disminuyeron el tiempo promedio de espera de 2 a 1 hora.

Después, implementé la interfaz en 6 sitios construidos específicamente en lugares cercanos a las viviendas de los pacientes con enfermedades crónicas como tuberculosis, VIH, diabetes, epilepsia, hipertensión y asma. El propósito de este proyecto fue "Llevar los medicamentos al paciente". Estos sitios cuentan con 6 Unidades de Dispensación Farmacéutica (PDU) similares a los cajeros automáticos, que disponen de una interfaz que permite al paciente comunicarse con un centro de asistencia telefónica farmacéutica. En el interior de cada PDU hay un gran robot que contiene varios miles de medicamentos. Mi aplicación envía una instrucción de dispensación al robot, que dispensa el artículo en una banda transportadora que lleva el medicamento hasta situarlo debajo de una impresora. A la impresora llega el contenido de una etiqueta farmacéutica con el nombre del paciente, las instrucciones de administración y otras notas. La impresora coloca y pega la etiqueta al envase del medicamento. El artículo se desplaza un poco más y una esponja presiona la etiqueta para fijarla con mayor firmeza al envase. La banda transportadora pasa el artículo a un contenedor de la PDU y, una vez que se suministran todos los artículos, el paciente puede abrir una ventanilla de la PDU y recoger los artículos. Lo más importante de este proyecto es que eliminó la necesidad de que los pacientes tengan que faltar al trabajo, recorrer largas distancias hasta la clínica donde se hace el seguimiento de su estado de salud, recoger sus medicamentos y volver a casa. Ubicar estos sitios en los vecindarios donde viven los pacientes permite que puedan acudir a cualquiera de estos sitios y recoger sus medicamentos en el camino hacia o de vuelta del trabajo. 

Desde el final de la época victoriana se han producido muy pocos cambios en el mundo de las farmacias. Los ingredientes ahora son más especializados y, en muchos casos, permiten salvar vidas. La penicilina, las vacunas, los analgésicos, las terapias contra el cáncer y las inmunoterapias han modificado nuestra capacidad de tratar enfermedades que históricamente habrían sido letales para los pacientes. Sin embargo, el proceso de dispensación de esos medicamentos ha permanecido estancado en las profundidades de las farmacias de los hospitales o de las farmacias de barrio que venden más cachivaches que medicamentos. La aplicación puede hacer mucho más que transferir las solicitudes de dispensación desde la aplicación farmacéutica a los robots, y estas funciones se detallan en el documento. La aplicación ha sido modificada para admitir los mensajes FHIR relacionados con el inventario, las solicitudes y respuestas sobre medicamentos y los certificados de los mismos. El documento viene en formato PDF.

Para aquellos a los que, en un momento dado, necesitan probar cómo va eso del ECP para escalabilidad horizontal (cómputo y/o concurrencia de usuarios y procesos), pero les da pereza o no tienen tiempo de montar el entorno, configurar los nodos, etc..., acabo de publicar en Open Exchange la aplicación/ejemplo OPNEx-ECP Deployment .

Como arquitecto de software, es un reto diseñar una arquitectura corporativa que cumpla con los requisitos actuales de los negocios. Hay que conseguir el nivel 5 de la imagen anterior.

Con InterSystems IRIS es posible. Con un solo producto, tienes SQL + NoSQL + ESB + BI + Open Analytics + Modelos analíticos virtuales en tiempo real + NLP + AutoML + ML (con Python) y cloudAvanzada + soporte a sharding.

¡Hola desarrolladores!

Estamos encantados de anunciar el lanzamiento delDirectorio de Partners de InterSystems.

A partir de ahora, éste será el lugar al que acudir para encontrar servicios y soluciones comerciales creadas con productos de InterSystems.

¿Por qué un Directorio de Partners de InterSystems?

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

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

Según un informe de 2020 de la Asociación de Examinadores de Fraude Certificados, se estima que las organizaciones de todo el mundo pierden un 5% de sus ingresos anuales debido al fraude.

La forma más eficiente de reducir el fraude es recopilar y unificar las transacciones, los activos y los datos de destino para identificar patrones, producir informes antifraude y algoritmos para validar las transacciones posteriores. En resumen, tenemos que seguir algunos de estos principios:

	Capacidad de recopilar, enriquecer y unificar datos sobre objetivos y activos			Fluidez en el procesamiento e intercambio de datos entre sistemas, equipos y fuentes de información internas y externas
	Base de datos corporativa multiformato y multimodelo sobre objetivos y activos			Uso intensivo de la Inteligencia Artificial aplicada al contexto empresarial
	Trabajo colaborativo basado en los hallazgos identificados por las automatizaciones			Redacción detallada de hallazgos y de expedientes, basados en herramientas analíticas flexibles y bien fundamentadas

Antes de que existieran plataformas de datos como InterSystems IRIS, el reto era difícil, ya que había:

Sistemas de inteligencia costosos, cerrados y especializados Pocas fuentes de datos y poca variedad Mucho trabajo manual Baja capacidad de colaboración Resultados poco precisos Solo podían trabajar los expertos

Sistemas abiertos (R and Python), más accesibles y amplios Explosión de formatos y fuentes de datos (Big Data) Automatización del 70% al 80% del trabajo de inteligencia Alta capacidad de colaboración Resultados muy precisos (uso avanzado de estadística y algoritmos de IA) Equipo multidisciplinar y autosuficiente

InterSystems IRIS tiene una excelente plataforma de datos para realizar una gestión antifraude:

Los beneficios son claros porque con un único producto, podemos:

1. Recopilar datos para analizar, crear patrones y algoritmos antifraude (en R y Python) utilizando la interoperabilidad de IRIS con BPL, Lenguaje de transformación de datos (DTL) y adaptadores de interoperabilidad. Y si algo es especial podemos utilizar la API nativa y PEX para desarrollar adaptadores de datos personalizados en Java, . NET o Python
2. Aplicar reglas y deduplicar datos utilizando BPL, DTL, ObjectScript y API nativa, con orquestración de interoperabilidad visual.
3. Almacenar datos multimodelos y producir resultados de datos como redes, PNL, SQL, NoSQL y OLAP con las bases de datos de InterSystems.
4. Todos estos datos se pueden utilizar con algoritmos de IA que funcionan con IRIS para predecir e identificar fraudes. Es posible utilizar IRIS IntegratedML (AutoML) para acelerar y mejorar el análisis antifraude.
5. Los equipos pueden producir expedientes e informes con los hallazgos utilizando IRIS Reports e IRIS BI y compartir todo esto con sistemas y personas a través del User Portal, Report Server e IRIS API Management.

En otras plataformas es necesario comprar otros productos como la base de datos SQL o NoSQL, Data Bus, ETL engine, Rules e Intelligence Server con soporte de machine learning, NLP engine, Analytics, Report Server y API Management Solution. Los costes son elevados, pero con IRIS es posible reducir estos costes, porque tenemos "todo en uno":

Esta publicación es la traducción de un artículo que publicó mi compañero Murray hace un tiempo. Durante mi trabajo en soporte la he recomendado muchas veces, pues lo que aquí se explica es bastante común y los ejemplos que se dan pueden ayudar a muchos de vosotros.

Una cuestión muy común es cuál es la configuración ideal para el servidor web Apache HTTPD cuando se utiliza con HealthShare. El propósito de este artículo es describir la configuración inicial recomendada del servidor web para cualquier producto HealthShare. 

Como punto de partida, se recomienda la versión 2.4.x (64-bit) de Apache HTTPD. Existen versiones anteriores como la 2.2.x, pero no se recomienda esta versión por rendimiento y escalabilidad de HealthShare.

Configuración de Apache

Módulo de la API de Apache sin NSD

HealthShare requiere la opción de instalación del módulo de la API de Apache sin NSD. La versión de los módulos vinculados de forma dinámica depende de la versión de Apache:

• CSPa24.so (Apache versión 2.4.x)

Es mejor dejar que la configuración de las Caché Server Pages (CSP) en el httpd.conf de Apache sea realizada por la instalación de HealthShare, la cual se explica en detalle más adelante en este documento. Sin embargo, la configuración puede realizarse manualmente. Para más información, consulta la Guía de Configuración de Apache que se encuentra en la documentación de InterSystems:  Opción recomendada: módulo de la API de Apache sin NSD (CSPa24.so)

Recomendaciones del Módulo de multiprocesamiento (MPM) de Apache

MPM Prefork de Apache vs. MPM Worker {#ApacheWebServer-ApachePreforkMPMVs.WorkerMPM}

El servidor web de Apache HTTPD incluye tres módulos de multiprocesamiento (Multi-Processsing Modules - MPM): Prefork, Worker y Event. Los MPM son responsables de conectar los equipos con los puertos de red, aceptar solicitudes y generar procesos hijos o secundarios que se encarguen de administrarlos. Por defecto, Apache se suele configurar con MPM Prefork, que no escala muy bien para un número de transacciones elevadas o altas cargas de trabajo de usuarios concurrentes.

En los sistemas de producción de HealthShare, el MPM Worker de Apache debería habilitarse por razones de rendimiento y escalabilidad. Se prefiere el MPM Worker por las siguientes razones:

• El MPM Prefork utiliza varios procesos secundarios con un hilo de ejecución (thread) cada uno, y cada proceso controla una conexión a la vez. Al utilizar Prefork, las solicitudes concurrentes se ven afectadas porque como cada proceso solo puede manejar una sola solicitud a la vez, las solicitudes se quedan esperando en cola hasta que se libere un proceso del servidor. Además, para escalar, son necesarios más procesos secundarios de Prefork, que consumen una gran cantidad de memoria.
• El MPM Worker utiliza varios procesos secundarios con muchos hilos de ejecución (thread) cada uno. Cada hilo de ejecución maneja una conexión al mismo tiempo, lo que es de gran ayuda para la concurrencia y reduce el uso de la memoria. Worker gestiona mejor la concurrencia que Prefork, ya que generalmente habrá hilos de ejecución libres disponibles para atender las solicitudes, en lugar de los procesos de Prefork con un solo hilo que podría estar ocupado.

Parámetros del MPM Worker de Apache {#ApacheWebServer-ApacheWorkerMPMParameters}

Utilizando hilos de ejecución para atender las solicitudes, Worker puede atender una gran cantidad de solicitudes empleando menos recursos del sistema que el Prefork utilizando procesos. 
Las directivas más importantes utilizadas para controlar el MPM Worker son ThreadsPerChild, que controla el número de hilos de ejecución desplegados por cada proceso hijo y MaxRequestWorkers, que controla el número total máximo de hilos que se pueden lanzar.
Los valores comunes de la directiva que se recomiendan para el MPM Worker se especifican en la siguiente tabla:

<th>
  Valor recomendado
</th>

<th>
  Comentarios
</th>

<td>
  Número máximo de usuarios simultáneos en el Visor Clínico de HealthShare, o el de otros componentes de HealthShare que se configuraron como la suma de todos los tamaños de grupo (*Pool Size*) de Business Services entrantes a todos los productos definidos por las producciones. 

Para más información, consulta la documentación correspondiente a la versión de Apache:

• Directivas comunes de Apache 2.4 MPM

Ejemplo para configurar el MPM Worker de Apache 2.4

En esta sección se especifica cómo configurar el MPM Worker para un servidor web Apache 2.4 de RHEL7, necesario para permitir hasta 500 usuarios simultáneos de TrakCare.

1. Primero, verificar el MPM mediante el siguiente comando:
2. Edita el archivo de configuración /etc/httpd/conf.modules.d/00-mpm.conf cuando sea necesario, agregando y eliminando el signo # para que solo se carguen los módulos MPM Worker. Modifica la sección MPM Worker con los siguientes valores, en el mismo orden que se indica a continuación:
3. Reinicia Apache
4. Después de que reinicie Apache correctamente, valida los procesos de worker ejecutando los siguientes comandos. Deberías ver algo parecido a lo siguiente, validando el proceso httpd.worker:

Fortalecimiento de Apache

Módulos requeridos de Apache

La instalación del paquete de distribución oficial de Apache habilitará, por defecto, un conjunto específico de módulos de Apache. Esta configuración predeterminada de Apache cargará estos módulos en cada proceso httpd. Se recomienda deshabilitar todos los módulos que no sean necesarios para HealthShare, por las siguientes razones:

• reducir el consumo de recursos del proceso httpd daemon,
• reducir la posibilidad de que falle la segmentación desde un módulo problemático,
• reducir las vulnerabilidades de la seguridad.

En la siguiente tabla se describen los módulos de Apache recomendados para HealthShare. Cualquier módulo que no se encuentre en la lista, se puede deshabilitar:

Cómo deshabilitar los módulos

Los módulos que no sean necesarios deben deshabilitarse para fortalecer la configuración y de esta manera reducir los puntos vulnerables en la seguridad. El cliente es responsable de las políticas de seguridad del servidor web. Por lo menos, deben deshabilitarse los siguientes módulos.

Apache SSL/TLS {#ApacheWebServer-ApacheSSL/TLS}

InterSystems recomienda que todas las comunicaciones que se realizan mediante TCP/IP entre los servidores y los clientes de HealthShare se cifren con SSL/TLS para proteger los datos durante las transferencias y garantizar la confidencialidad y la autenticación. Además, InterSystems también recomienda que se utilice HTTPS para llevar a cabo las comunicaciones entre los navegadores (clientes) de los usuarios y la capa del servidor web de la arquitectura propuesta. Asegúrate de consultar las políticas de seguridad de tu empresa, para garantizar que cumple con cualquier requisito de seguridad específico que tenga. 

El cliente es responsable de suministrar y administrar los certificados SSL/TLS.
Si utilizas certificados SSL, agrega ssl_module (mod_ssl.so).

Parámetros adicionales para el fortalecimiento de Apache

Para fortalecer aún más la configuración de Apache, realiza los siguientes cambios en httpd.conf:

• TraceEnable debe desactivarse para evitar posibles problemas de seguimiento entre sitios.

• ServerSignature debe desactivarse para que no se visualice la versión del servidor web.

Parámetros de configuración suplementarios de Apache {#ApacheWebServer-SupplementalApacheConfigurationParameters}

Keep-Alive {#ApacheWebServer-Keep-Alive}

La configuración de Apache Keep-Alive permite utilizar la misma conexión TCP para la comunicación mediante HTTP, en vez de abrir una nueva conexión para cada nueva solicitud, es decir, Keep-Alive mantiene una conexión persistente entre el cliente y el servidor. Cuando la opción Keep-Alive está habilitada, la mejora en el desempeño proviene de la descongestión de la red, la reducción de la latencia en las subsiguientes solicitudes y el menor uso del CPU ocasionado por la apertura simultánea de las conexiones. Keep-Alive está ACTIVO por defecto y el estándar HTTP v1.1 requiere que se asuma.

Sin embargo, hay ciertas condiciones para habilitar Keep-Alive; Internet Explorer debe ser la versión 10 o superior para evitar problemas como el tiempo de espera, que se presenta en las versiones anteriores de Internet Explorer. Además, intermediarios como firewalls, balanceadores de cargas y proxies, etc., pueden interferir con las “conexiones TCP persistentes” y pueden ocasionar el cierre imprevisto de las conexiones.  

Cuando se habilita Keep-Alive, su tiempo de espera también debe ser ajustarse. El tiempo de espera predeterminado de Keep-Alive para Apache es excesivamente bajo, y debe aumentarse en la mayoría de las configuraciones debido a que pueden surgir incidencias asociadas con la interrupción de las solicitudes AJAX (es decir, hipereventos). Estas incidencias pueden evitarse si se asegura que el tiempo de espera de Keep-Alive en el servidor es mayor que para el cliente.  En otras palabras, el cliente debe cumplir con el tiempo de espera y cerrar la conexión en vez de que lo haga el servidor.  La mayoría de las veces los problemas ocurren (en Internet Explorer más que en otros navegadores), cuando el navegador intenta utilizar una conexión (particularmente para una PUBLICACIÓN) que se supone que estaría abierta. 

Consulta los siguientes valores recomendados de KeepAlive y KeepAliveTimeout para un servidor web HealthShare.

Para habilitar KeepAlive en Apache, realiza los siguientes cambios en httpd.conf:

CSP Gateway

Para el parámetro KeepAlive de CSP Gateway, deja el valor predeterminado de No Action, porque el estado de KeepAlive se determina por los encabezados de respuesta HTTP de cada solicitud.

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/.

InterSystems IRIS es una excelente opción para desarrollar proyectos de aprendizaje automático (Machine Learning, ML), en escenarios de operaciones con datos masivos, debido a las siguientes razones:

1. Soporta el uso de shards para escalar el repositorio de datos, tal y como MongoDB por ejemplo.
2. Soporta la creación de cubos analíticos, y si unimos esto más el "sharding" nos permite tener volumen y rendimiento.
3. Soporta la recopilación de datos de forma planificada o en tiempo real, con una gran variedad de opciones de adaptadores de datos.
4. Permite automatizar todo el proceso de de-duplicación, utilizando lógica en Python u ObjectScript.
5. Permite organizar y automatizar el flujo de datos al repositorio, usando flujos visuales (BPL) y el Lenguaje para la transformación de datos (DTL).
6. Soporta el escalamiento automático avanzado, mediante Docker (IaC) y los scripts de Cloud Manager.
7. Soporta la carga de librerías ObjectScript in provisioning, mediante ZPM.
8. Dispone de interoperabilidad con Python y R para realizar ML en tiempo real.
9. Permite utilizar un motor AutoML, denominado IntegratedML para ejecutar el mejor algoritmo para el conjunto de datos indicados.
10. Permite crear análisis posteriores a la ejecución, como predicciones y clasificaciones de AutoML, salidas desde los procesos cognitivos de Python y R, tablas dinámicas de Inteligencia empresarial (BI), todo ello con visualizaciones propias o de terceros.
11. Permite crear vistas e informes avanzados con JReport.
12. Permite maximizar la reutilización y monetización de los datos con el API Management incluido. 

En los recientes trabajos de benchmarking a gran escala, observamos un tiempo excesivo de uso del CPU %sys que afectó negativamente en la escalabilidad de la aplicación.

Problema

Encontramos que gran parte del tiempo se pasó llamando a la llamada localtime() del sistema, debido a que la variable de entorno TZ no estaba configurada. Se creó una rutina de prueba sencilla para confirmar la observación, y las diferencias entre el tiempo transcurrido y los recursos que necesitó la CPU con la variable TZ vs. cuando TZ no estaba establecida, fueron extraordinarios. Se descubrió que el uso hereditario de las llamadas stat() de sistema hacia /etc/local_time desde localtime() es muy costoso cuando la variable TZ no está establecida.

Recomendación

InterSystems recomienda encarecidamente que se confirme en cualquier sistema que tenga Linux instalado, ya sea en x86 o Linux on Power, que la variable de entorno TZ está configurada adecuadamente, para obtener un rendimiento óptimo. Para más información, consulta: "man tzset".

La versión de prueba de Caché 2016.1 contiene optimizaciones relacionadas con las funciones de fecha y hora, y las pruebas iniciales indican importantes mejoras. A continuación, se muestran ejemplos de salidas, resultado de probar las nuevas llamadas a funciones internas en un bucle con Linux on Power, donde en ambos casos TZ *no* se establece:

Antes de Caché 2016.1 FT:

real	0m22.60suser	0m1.64ssys	0m20.89s

Con Caché 2016.1 FT:

real	0m0.40s
user	0m0.37s
sys	0m0.00s

Publica tus comentarios sobre cualquier experiencia que hayas tenido con tu aplicación, relacionada con la variable de entorno TZ, y también sobre el impacto que la versión de prueba de Caché 2016.1 tiene con o sin la variable TZ definida.

Algunos clientes me preguntan sobre la migración de Caché a IRIS. ¿Por qué migrar a IRIS? Caché es excelente, estable y ofrece un buen rendimiento...

Estos clientes tienen razón pero, en los últimos años, la transformación digital requiere soluciones más completas para adaptarse a las nuevas necesidades. E InterSystems fue visionaria en entenderlo y por ello lanzó IRIS al mercado.
InterSystems IRIS es una plataforma de datos lista para el reto de la transformación digital. Y para demostrarlo, he creado una Propuesta de Valor ("Value Canvas").

Los sistemas de bases de datos tienen requisitos muy específicos para las copias de seguridad ("backups") que, en entornos empresariales, necesitan una previsión y planificación. En el caso de los sistemas de bases de datos, el objetivo de una copia de seguridad es crear una copia de los datos en un estado equivalente a cuando la aplicación se apaga de forma correcta. Las copias de seguridad consistentes con las aplicaciones cumplen estos requisitos, y Caché ofrece un conjunto de APIs que facilitan la integración con soluciones externas para lograr este nivel de consistencia en las copias de seguridad.

Versión PDF: https://github.com/yurimarx/iris-periodic-table/raw/master/periodic%20table%20iris.pdf

GIT sources: https://github.com/yurimarx/iris-periodic-table