Los errores más frecuentes al renovar o adquirir almacenamiento

Han pasado 5 años y toca renovar el storage. ¿Cuales son los errores más habituales?

La renovación de los sistemas almacenamiento empresarial, es una decisión crítica, compleja y con unos costes que hacen muy recomendable que sea abordado con mucho cuidado. Es común que se cometan errores al planificar y llevar a cabo este tipo de proyectos y en este artículo, vamos a comentar aquellos que nos encontramos con mayor frecuencia en nuestros nuevos clientes.

1. Dimensionamiento incorrecto

Uno de los errores más comunes al renovar el almacenamiento empresarial es subestimar o sobreestimar la capacidad (en TB, rendimiento y tiempo de respuesta) necesaria de almacenamiento. Un dimensionamiento incorrecto puede resultar en una inversión insuficiente o en una inversión excesiva en almacenamiento empresarial. Todos sabemos que una solución con NVMe es más rápida que otra con SSD, pero ¿la necesitamos? ¿y para el 100% de los datos? ¿a qué precio? ¿los servidores son capaces de alcanzar el ancho de banda que permite la cabina? (pista:  en el 95% de los casos no). Pero claro para saberlo es recomendable realizar un dimensionamiento o auditoría previa, que tiene un coste muy pequeño en comparación con la adquisición de las cabinas y lo que nos podemos llegar a ahorrar. Las prisas y las ofertas para mañana no son buenas compañeras de viaje en este tipo de proyectos.

2. No prever el coste a, al menos, 5 años

Uno de nuestros clientes compró hace años unas cabinas de uno de nuestros fabricantes favoritos. Era extremadamente potente y el precio era muy atractivo. Dos años después, quisieron añadir discos (la compraron con lo mínimo) y el precio de lista de los mismos superaba el millón de euros. Es más, todos los ejercicios mostraban que era más económico comprar una nueva cabina de menor gama pero con rendimiento más que suficiente y el almacenamiento que necesitaban, que ampliar la existente. ¿Absurdo? No, una mala praxis comercial muy habitual entre empresas sin personal técnico propio. Igual que nos regalan las impresoras, con muchos otros componentes de HW ocurren cosas similares. Switches que se licencian por puerto activado, cortafuegos cuyo precio varía según los usuarios que se conecten y otros miles de trucos para ocultar los costes en el medio y largo plazo, así como las dependencias generadas y la obligación de comprar servidores y cabinas adicionales cada poco tiempo. Si bien lo hacen todos los fabricantes, con un correcto asesoramiento muchas veces se le puede dar la vuelta y en el momento de la compra conseguir a un precio muy interesante todo lo que necesitemos mientras la máquina funcione.

3. No conocer el ciclo de vida de las máquinas (hasta cuándo tendrán mantenimiento)

Otro error frecuente es no comprender el ciclo de vida de las máquinas y no saber hasta cuándo estarán disponibles los servicios de mantenimiento. Es fundamental tener en cuenta la vida útil de las cabinas de discos y la disponibilidad de servicios de soporte técnico y mantenimiento en el medio y largo plazo. Muchas veces los sistemas al final de su ciclo de comercialización tienen importantes descuentos… pero es que también durante su lanzamiento. Lo segundo nos permite usarlos durante mucho más tiempo  reduciendo el coste anual significativamente. Si compramos una cabina que va a ser retirada de marketing próximamente, puede que cuando la hayamos puesto en funcionamiento solo le queden los años mínimos de soporte y a los 5 años la única alternativa sea soportarla nosotros mismos, pedir las piezas que fallen en brokers internacionales o comprar una nueva. Si hubiéramos adquirido un sistema que llevara poco en el mercado (aunque lo suficiente para que otros lo hayan probado y sufrido sus primeros fallos) será sencillo extender el mantenimiento durante 6, 7 o incluso 10 años que suele ser el tope de su ciclo de vida habitual. Los comerciales de empresas sin personal técnico te dirán “no se podía saber” o que “la culpa es de IBM / HP / Dell / Hitachi” pero no es cierto. Tenemos que saber lo que vendemos e informar a nuestros clientes de manera honesta sobre los pros y os contras de cada nueva infraestructura que les propongamos adquirir.

4. Desconocer las matrices de compatibilidad con los sistemas operativos

Otro error común es no considerar la compatibilidad del almacenamiento empresarial con los sistemas operativos existentes. Es fundamental asegurarse de que el storage sea compatible con los sistemas operativos existentes y que si debemos actualizar, lo hagamos antes de la puesta en marcha del nuevo almacenamiento. Esto es especialmente relevante cuando hay sistemas operativos fuera de soporte por la falta de de un servicio mantenimiento preventivo. Igual la nueva cabina soporta Red Hat o Windows, pero no la versión en producción porque todo nuevo hardware requiere drivers que sería raro existieran antes. Los viajes en el tiempo tampoco existen para los sistemas operativos, y un Windows de 2008 es probable que tenga problemas  de compatibilidad con una cabina de 2023.

5. No preveer el impacto de las migraciones de los entornos de producción existentes

Por último, otro error común es no prever el impacto de las migraciones de los sistemas existentes en el almacenamiento que hemos renovado. Es importante evaluar cuidadosamente los sistemas existentes que se migrarán y comprender cómo se integrarán en la nueva solución de almacenamiento,  quien se encargará de estos servicios profesionales y qué impacto tendrán en nuestra organización o negocio.

6. No tener un equipo técnico formado ni un soporte L2-L3 al que recurrir

Muchos clientes compran sistemas almacenamiento pero no tienen el tiempo para formarse en ellos ni disponen de servicios de soporte técnico externo al que recurrir, pensando que ante cualquier problema pueden recurrir al fabricante pues ya pagan un soporte por estos sistemas, cuando no siempre es así, sobretodo si el sistema funciona correctamente y el problema, aunque muy relacionado, es otro.

7. Confiar en empresas que no tienen equipos técnicos y cuyo negocio se basa en grandes márgenes en las ventas de SW y HW

A diferencia de nuestra competencia, en Sixe Ingeniería siempre nos pondremos del lado de nuestros clientes, pues vivimos fundamentalmente de la formación, consultoría y soporte técnico. Servicios que complementamos con la venta de HW que normalmente ayudamos a mantener, con lo que somos los principales interesados en que las soluciones sean las idóneas en el medio y largo plazo. Además, como partners de referencia de IBM y Lenovo, podemos ofreceros importantes descuentos, conocemos muy bien la mayoría de los tipos de entornos críticos y somos agnósticos en cuanto a tecnología, aunque tenemos nuestras preferencias en base a nuestra experiencia. ¿Hablamos?

Servidores IBM Power10 para SAP HANA a un precio imbatible

IBM ha publicado su última oferta en cuanto a servidores de alto rendimiento Power10 para SAP HANA, que se basa en su gama de servidores de uno y dos sockets con entre 2TB y 6 TB de RAM con descuentos de casi el 50%.

SAP HANA funciona gracias a un diseño donde el procesamiento y análisis en tiempo real de grandes volúmenes de datos se realiza íntegramente en memoria garantizando un rendimiento muy mejorado con respecto a los entornos de SAP clásicos. HANA ayuda a empresas de todo el mundo a administrar datos críticos y tomar decisiones empresariales basadas en información precisa y obtenida en tiempo real.

¿Qué aporta IBM Power10?

El Power10 de IBM es el primer servidor que ofrece soporte nativo para SAP HANA, lo que lo convierte en una opción atractiva para las empresas que buscan implementar esta plataforma. Con su capacidad para manejar grandes volúmenes de datos y realizar análisis en tiempo real, el Power10 puede mejorar significativamente la eficiencia y la eficacia de las operaciones empresariales.

Leer más

“El comercial me ha engañado” o porqué necesitas un servicio de Radar Tecnológico

El título de este artículo, “el comercial me ha engañado”, es uno de los comienzos más habituales en nuestras conversaciones con nuevos clientes. Grandes proyectos con escaso retorno cuando no directamente la omisión de información clave que de haberla conocido hubiera cambiado el trasncurso de las decisiones estratégicas en tecnología. Increibles pliegos donde alguien se olvida de los servicios profesionales necesarios para que la solución se ponga en marcha, o de la correcta formación del personal que la explotará los años venideros. Leer más

Alma & CentOS Linux en servidores IBM Power

Durante los últimos dos añs, el proyecto CentOS, distribución comunitaria de Linux basada y binariamente compatible con Red Hat, no ha parado de sufrir cambios. Al igual que ocurre en otros proyectos de software libre, esta popular (y estable) distribución usada por empresas y organismos de todo el mundo, pasaba a ser una “versión de desarrollo” de Red Hat Enterprise Linux. Lo mismo ocurre con oVirt vs RHEV o Foreman + Katello vs Satellite. A cambio, Red Hat ofrece licencias gratuitas para pequeños despliegues y ha ampliado las opciones de suscripciones educativas.

¿Que ocurre con CentOS Stream?

No es que CentOS Stream ya no sea estable, o que sus usuarios se conviertan sin quererlo en beta-testers de Red Hat Enterprise, pero cambiaban aspectos fundamentales. Hasta ahora, cuando Red Hat saba su versión X, unos meses después, se compilaban las mismas versiones de los mismos paquetes creando un “clon” con las mismas funcionalidades para quienes no necesiten un soporte de nivel empresarial. Esto deja de ser así (las actualizaciones y cambios pasan a ser más frecuentes) y, por todo el mundo, sus usuarios se plantean qué hacer. Por ejemplo el CERN de Suiza, ha decidido quedarse con CentOS Stream por el momento. Quizás por aquello de que más vale malo conocido que bueno por conocer.. pero esa es otra historia.

En paralelo, tanto Ubuntu, como Red Hat y SUSE ofrecen todos sus repositorios para x86 pero también para ARM y ppc64le (Linux on IBM Power), con lo que estábamos muy interesados en probar si estas nuevas distribuciones herederas de CentOS, estaban siendo compiladas para estas arquitecturas y si podíamos migrar a ellas desde CentOS Stream. De ser así pensamos que puede ser un buen aliciente para que clientes que dispongan (o se estén planteado adquirir) servidores IBM Power le den una oportunidad a esta tecnología, que de desplegarse satisfactoriamente no solo se consigue un mucho mejor rendimiento por core, sino que los costes en licencias y las horas necesarias para el mantenimiento técnico se reducen mucho.

Alma vs CentOS, Rocky y Oracle Linux

En esta tabla tenemos las distribuciones basadas en Red Hat que podemos (o podremos) instalar en IBM Power, y sus características fundamentales.

Benchmarking against RHEL AlmaLinux Oracle Linux Rocky Linux CentOS Stream CentOS Linux
Disponible desde Marzo 2021  2006  Junio 2021  2019  2004
Compatibilidad binaria 1:1 con RHEL Si Casi *
(cambios en glibc, openssl..)
Si Aplican los límtes de la ACG Si
Actualizaciones cada Diarias Diarias Diarias Upstream de RHEL Diarias
Ciclo de vida 10 Years 10 Years 10 Years 5 Years EOL on 2021-12-31
Soporte comercia Terceros Oracle, terceros Terceros Terceros Terceros
Soporte para PowerPC  Si Si No todavía Si Si
Soporte para s390x  No todavía Por decidir Por decidir Si Si
Propiedad de: AlmaLinux OS Foundation Oracle Inc Rocky Enterprise Software Foundation Red Hat Inc Red Hat Inc
Tipo de organización del propietario Non-Profit 501(c)6 For Profit C-Corp For Profit, Public Benefit Corp For Profit C-Corp For Profit C-Corp

Como veis, si buscamos una alternativa a CentOS Linux para Power, AlmaLinux parece ser la opción más interesante y con 10 años de actualizaciones en cada versión.

Probando AlmaLinux (ppc64le)

Para escribir este artículo hemos hecho dos tipos de pruebas. La primera de ellas ha sido instalar desde el DVD AlmaLinux en un servidor Power8. Como veis más allá del arranque desde el SMS de la LPAR la instalación es igual que en un sistema x86

¿Y si queremos migrar desde CentOS Stream a AlmaLinux?

Existe un script que podeis descargar aquí, que hemos descargado en un segundo entorno con un CentOS Stream recién actualizado.

$ wget https://raw.githubusercontent.com/AlmaLinux/almalinux-deploy/master/almalinux-deploy.sh

Es necesario editar este script antes de ejecutarlo

$ vi almalinux-deploy.sh

Y modificar la siguiente línea, donde verifica la arquitectura porque ppc64le SI ESTÁ SOPORTADA y tenemos todos los paquetes de software disponibles (lo vamos a comprobar).

A continuación ejecutamos el script, que probablemente necesites lanzar con la opción -d para hacer un “downgrade” desde la versión actual de CentOS Stream a AlmaLinux 8.X (siempre será algo más antigua que la última de CentOS Stream)

 

Y a continuación puedes instalar epel-release y el resto de repositorios con software adicional como harías en cualquier entorno x86.

Al ser un entorno IBM Power, es recomendable instalar los paquetes de software que añaden funcionalidades (en base a comandos de AIX) para poder administrar correctamente todo el HW, acceder a la consola HMC y poder realizar cambios de configuración sin reiniciar los sistemas.

$ yum install wget 
$ wget ftp://public.dhe.ibm.com/software/server/POWER/Linux/yum/download/ibm-power-repo-latest.noarch.rpm
$ rpm -ivh –nodeps ibm-power-repo-latest.noarch.rpm

Aquí, una vez más hay que editar el script de configuración para que funcione en AlmaLinux. Verás que hay un exit 1 si no es centos/suse/redhat que vamos a modificar quedando así

$ vi /opt/ibm/lop/configure

$ chmod +x /opt/ibm/lop/configure

$ /opt/ibm/lop/configure

Instalamos el repositorio de epel (contiene mucho software adicional)

$ yum install epel-release

Y vemos como los nuevos repositorios están ya activos

$ yum repolist

migra

Descargamos las utilidades de PowerVM para que la LPAR de Linux sea gestionada desde el HMC

$ yum install src ksh rsct.core devices.chrp.base.ServiceRM DynamicRM

Y reiniciamos los servicios de RMC (que nos valen para añadir o quitar memoria y cpu de manera dinámica)

$ /usr/bin/rmcctrl -z
$ /usr/bin/rmcctrl -A
$ /usr/bin/rmcctrl -p

La prueba final

Vamos a usar un script de bastantes lineas para desplegar un servidor web, base de datos y un sitio con WordPress.

$ wget https://github.com/UncleDan/linux-scripts/blob/master/wordpress-centos8.sh

$ bash wordpress-centos8.sh

Entramos en nuestra IP con el navegador y Wodpress funcionado! Esto es algo que hace dos años no podíamos decir que funcionara con esta seguridad. Nos alegra comprobar que se han hecho muchos avances y que el soporte de aplicaciones para ppc64le es cada vez más extenso y completo. Os animamos a probarlo y sin necesidad de invertir en nuevas licencias.

¿Qué otras aplicaciones y servicios podemos desplegar en Linux sobre IBM Power?

Para acabar este artículo os dejamos un listado de aplicaciones disponibles en OpenShift para Power y que por lo tanto, están totalmente soportadas en cualquier distribución basada en Red Hat, como son AlmaLinux y CentOS. ¿A qué esperas para probarlo?

Sistemas operativos bajo contenedores (docker / runC)

+ Red Hat
+ CentOS
+ SUSE
+ BusyBox
+ AlpineLinux
+ Ubuntu
+ Debian

Middleware

+ WebSphere Liberty
+ Open Liberty
+ Apache Tomcat
+ ActiveMQ
+ JBoss
+ WildFly
+ RabbitM
+ WordPress

Lenguajes

+ Jenkins
+ Ansible
+ Kubernetes
+ Red Hat OpenShift
+ Gradle
+ Maven
+ Terraform
+ Travis CI
+ Python
+ Java
+ PHP
+ GoLang
+ OpenJDK
+ NodeJS
+ R
+ Ruby

 

Bases de datos

+ MongoDB
+ Redis
+ MySQL
+ Cassandra
+ MariaDB
+ PostgreSQL
+ Memcached
+ IBM Db2

Analíticas & IA

+ Grafana
+ Kibana
+ Elasticsearch
+ Logstash
+ Fluentd
+ Kafka
+ IBM Watson Studio
+ IBM Watson ML

Almacenamiento

+ Container Storage Interface
+ IBM Spectrum Virtualize
+ IBM PowerVC CSI Driver
+ NFS

Comunicaciones

+ Prometheus
+ Nginx
+ Apache HTTP Server
+ ZooKeeper
+ HAP oxy
+ etcd

 

Mitos, verdades y nuestra opinión sobre los IBM Cloud Paks

Con la compra de Red Hat por parte de IBM, el conjunto del portfolio de soluciones de software para ciberseguridad, aplicaciones, bases de datos, automatización y gestión de nubes híbridas se ha ido portando a OpenShift bajo la marca IBM Cloud Paks. Esto implica que muchas de estas aplicaciones se ha rediseñado y adaptado para funcionar sobre contenedores (aunque algunas como QRadar ya lo hacían desde hace años) y ser controladas por Kubernetes, que es el orquestador de contenedores en el que se basa OpenShift.

¿Cómo se despliegan los IBM Cloud Paks?

Los Cloud Paks de IBM se instalan sobre un entorno PaaS con OpenShift tanto en data centers propios sobre IBM Power Systems, VMWare, KVM (RHEV / LinuxONE) como en las nubes públicas de Microsoft (Azure), IBM, Amazon (AWS) y Google (GCP). Gracias a IBM Satellite se puede desplegar en una combinación de recursos propios y en la nube, mediante una arquitectura híbrida y flexible. Nuestro departamento de servicios profesionales puede ayudaros.

¿Como se licencian IBM Cloud Paks? ¿Cuanto cuestan?

Esto es quizás una de las partes menos conocidas y a nuestro juicio más polémicas. IBM siempre ha vendido licencias perpetuas para todas su soluciones software. Estas licencias vienen con un soporte técnico básico para incidencias HW y otro más avanzado para el SW (SWMA) que se pueden ir renovando típicamente cada 3 años. Al pasar a un entorno “cloud” vamos hacia sistemas de pago por uso, muy escalable y para qué engañarnos, a veces complicado de estimar. Por ejemplo, en el de Data tiene estos precios por “core virtual”. Es decir, desde unos cientos de dólares hasta a unos cuantos cientos de miles.. :)

Esto tiene ventajas evidentes para soluciones donde el soporte lo razonable que se vaya renovando como es el caso de soluciones abiertas y extremadamente complejas como las basadas en micro-servicios y contenedores. Los clientes que no estén cómodos con este modelo, pueden seguir comprando appliances o licencias para desplegar en su infraestructura muchas de estas soluciones mediante un único pago y un soporte opcional a renovar cada varios años. En otras, este es el único modelo pues son soluciones nativas para entornos basados en Kubernetes y Cloud.

¿Necesito tener OpenShift para instalar un Cloud Pak de IBM?

Respuesta corta: si. Ahora bien, si no lo tienes, lo puedes desplegar sin demasiados problemas gracias a los instaladores incluidos en las últimas versiones tanto en tu propia infraestructura como en una externa (IaaS) de tu proveedor de cloud favorito.

¿Merecen la pena los IBM Cloud Paks?

Como buen verso libre que somos en el sector de los integradores de sistemas, pensamos que algunos si, y otros no tanto (al menos por ahora). Depende del uso que se les vaya a dar, de la dependencia que tengamos con otras aplicaciones y del nivel de madurez en la adopción de contenedores y uso de kubernetes de nuestra organización. Si estamos empezando con Dockers, OpenShift y entornos Cloud, quizás es mejor ceñirnos a un buen plan de transformación y modernización digital en vez de “empezar la casa por el tejado”.

¿Hay cursos o formación de IBM Cloud Paks?

Para poder aprovechar esta tecnología necesitas dominar tanto la infraestructura (OpenShift) de la cual hay formación oficial ofrecida por Red Hat, y un taller intensivo y práctico elaborado por nosotros mismos. Una vez que la infraestructura esté bajo control tendrás que formarte en los diferentes productos y soluciones de IBM que te interesen, pues no dejan de ser colecciones de Software agrupadas por categoría y licenciadas conjuntamente. Por ejemplo, el Cloud Pak for Security, es fundamentalmente IBM QRadar SOAR Platform  mientras que el Cloud Pak for Applications incluye toda la suite de Websphere.

Lo dicho, si queréis, hablamos.

 

Nueva certificación de analista en ciberseguridad con QRadar SIEM 7.4.3

Acaba de salir de la primera de las nuevas certificaciones de IBM QRadar SIEM. Como siempre, han empezado por la más sencilla, la de analista. Está destinada a profesionales que deseen validar sus conocimientos sobre QRadar SIEM en la versión 7.4.3. El exámen es el C1000-139, titulado “IBM Security QRadar SIEM V7.4.3 – Analysis” y la certificación que se obtiene es la de “IBM Certified Analyst – Security QRadar SIEM V7.4.3

Como sabéis (y si no, os lo contamos) la principal novedad en la versión 7.4 es el cambio de interfaz de usuario. Han ido incluyendo paneles de control y de monitorización que permiten mejorar la visibilidad de los incidentes de seguridad con mapeos concretos a metodologías como MITRE ATT&CK. No deja de ser una manera de estandarizar los incidentes, dar un poco de abstracción al producto, proporcionarnos una visión de más alto nivel sobre lo que está sucediendo, más alla de las reglas concretas que han ido aplicando y las cadenas de eventos que se han generado.

Como requisitos previos (no forma parte del examen) es necesario dominar:

  • Conceptos de SIEM (qué es, qué no y para qué sirve)
  • Dominar la teoría de redes TCP/IP
  • Tener un buen conocimiento de terminología de seguridad informática.
  • Conocer los diferentes módulos y plugins de QRadar como son Network Insights o Incident Forensics.

¿Por qué nos preguntan en el exámen?

  • Análisis de ofensas y eventos de seguridad (logs, flujos de red, etc)
  • Comprensión de los listados de datos de referencia (sets, maps, tables, etc)
  • Dominar las reglas y los “building blocks”
  • Saber buscar en informes, crearlos desde cero, programarlos, modificarlos, etc.
  • Tener un conocimiento básico de la arquitectura de QRadar, fundamentalmente sus componentes, licenciamiento y configuración a nivel de red.
  • Por último, las configuraciones multi-dominio y multi-cliente que parece están cada vez más de moda, tienen un apartado dedicado en este exámen.

¿Me debo re-certificar?

En nuestra opinión, si estás certificado en versiones 7.2.X o 7.3.X no hay necesidad alguna de volver a certificarse. Otra cosa es que tu empresa lo requiera para mantener cierto nivel de partner con IBM o sea requisito para alguna licitación pública. Eso si, si vas a certificarte, aprovecha y hazlo cuando vayan saliendo las nuevas versiones.

¿Cuando saldrán el resto de certificaciones en 7.4.2?

Entre este trimestre y el que viene saldrán las de “administrator” y “deployment professional”.  Las diferencias entre todas ellas las cubrimos hace tiempo en este artículo. Aunque cambien las versiones, los tipos de exámenes y sus objetivos son los mismos.

¿Nos podéis ayudar con QRadar?

Claro, ofrecemos formación, servicios profesionales, soporte y también vendemos y renovamos sus licencias. Contáctanos y hablemos.

Actualiza tus IBM Power9 o quizás tus LPARs no arranquen

Muchas veces obviamos la necesidad de realizar actualizaciones preventivas no solo del sistema operativo (AIX, Linux, IBM i) sino también del FW de los servidores IBM Power. IBM publica correcciones para los problemas que otros clientes han experimentado y normalmente no es necesario que tú también lo hagas. De paso mantenemos nuestros sistemas seguros ante todo tipo de amenazas y vulnerabilidades tanto externas como internas.

El problema del que os hablamos en este breve artículo es un error que impedía el arranque de las LPAR en los servidores Power9 si llevaban más de 814 días funcionando. Suena un poco al de las impresoras de hace unos años que fallaban al imprimir varios cientos de miles de páginas, nunca sabemos si adrede o por un error. En el caso de IBM es un fallo reconocido de firmware que se soluciona con la actualización VH950_045_045 / FW950.00 disponible desde el 23 de Noviembre de 2020. Así que si sois algún cliente de IBM donde en los últimos dos años, vuestros ya veteranos sistemas Power9 no se han actualizado, tendréis posiblemente este problema en lo que queda de año.

Os damos una pista, el error es el CA000040 que impide el arranque de la LPAR y cuya solución provisional podría ser usar el modo compatibilidad con Power8 desde el HMC o ASMI mientras instaláis las actualizaciones pendientes.

En Sixe Ingeniería mantenemos preventivamente los sistemas IBM Power de nuestros clientes desde hace más de 15 años. Podemos ayudaros a monitorizar, actualizar y mantener de manera preventiva toda vuestra infraestructura de servidores y almacenamiento IBM y Lenovo. También os ayudamos a minimizar el gasto en licencias y os ofrecemos los mejores precios en las actualizaciones a nuevas generaciones de servidores IBM Power. Contáctanos para más información.

Instalamos y probamos el nuevo IBM AIX 7.3

Tras unirnos al programa OpenBeta de IBM, hemos podido descargar y probar la nueva versión de AIX 7.3 que llega en su 35 aniversario.

Entre sus novedades destacan:

  • Los frameworks de Python y Bash que funcionan directamente con AIX, ¡no tendremos que volver a instalarlos manualmente!
  • Soporte para el comando dnf (standard en Red Hat) para la instalación de paquetes de código abierto desde el AIX Toolbox. AIX habla Linux desde hace mucho tiempo, pero desde la versión 7.3 está cada vez más integrado facilitando a los desarrolladores y administradores de sistemas todas las ulilidades necesarias para modernizar los entornos UNIX.
  • Reducción del tiempo para añadir dinámicamente procesadores/memoria a una LPAR en funcionamiento, de gran ayuda en LPARs con bases de datos que usen cientos de GB o varios TB de memoria RAM. Esto se une a la reducción de los tiempos de arranque (IPL) para este tipo de particiones
  • Los comandos pigz y zlibNX ahora utilizan de forma transparente la aceleración GZIP de NX en Power9 y Power10
  • Soporte mejorado para el cifrado de volúmenes lógicos (LVM) para incluir rootvg y dispositivo de dump.
  • La pila de protocolos TCP ahora es compatible con CUBIC,  un algoritmo que evita la congestión de la red TCP que puede conseguir conexiones de gran ancho de banda a través de las redes de forma más rápida y fiable.
  • Mejoras adicionales en la seguridad IP (IPsec)
  • Posibilidad de crear un archivo OVA a partir de un mksysb mediante el comando create_ova con el objetivo de agilizar los despliegues en cloud (PowerVS) e híbridos.
  • Creación de una imagen ISO a partir del nuevo comando mksysb_iso
  • Integración con los nuevos compiladores IBM Open XL C/C++ y Fortran
  • Aumento del tamaño de los archivos y del sistema de archivos
  • Mejora de la compatibilidad con Ansible y Ansible Tower
  • Integración con PowerVC 2.X

 

Conoce los nuevos servidores IBM Power10 y AIX 7.3

The Power of 10

El 8 de Septiembre es la fecha del anuncio oficial de los nuevos servidores de IBM con procesadores Power10 que vendrá seguido del anuncio de la versión 7.3 de AIX, que ha cumplido en 2021 35 años. Teniendo en cuenta las características técnicas disponibles sabemos que incorporan memoria DDR5, una interfaz PCIe 5.0 y que están diseñados utilizando una tecnología de 7nm de Samsung. Los procesadores Power10 volverán a disponer de dos “sabores”. Uno con 15 cores en modo SMT-8 (ideal para AIX e IBM i) y otros con 30 cores y SMT-4 pensado para cargas de trabajo basadas exclusivamente en Linux. Los chips de Power10 incorporan también grandes mejoras para Inteligencia Artificial (IA), permitiendo ejecutar cargas de Machine Learning hasta 20 veces más rápido que POWER9.

Un millón de SAPS. La infraestructura importa y mucho.

Como es habitual, los primeros sistemas que se anunciarán serán los tope de gama (scale-up) diseñados para entornos altamente virtualizados con aplicaciones que requieren de unos recursos ingentes como SAP HANA. Los benchmarks publicados indican que se consiguen 1 millón de SAPS con 120 cores, es decir la mitad de cores de los que se necesitaban en la generación anterior de Power9 en servidores E980. Comparando con servidores actuales de otros fabricantes disponibles este año, HPE consiguió unos 670.000 SAPS (lo que equivale a unos 120.000 usuarios concurrentes) usando 224 núcleos en su Superdome Flex 280 basados en los procesadores más potentes de Intel (los Xeon Platinum). Para los que esto no os diga gran cosa, la otra lectura es que el rendimiento por core se ha seguido mejorando y mucho mientras el resto de fabricantes lo mantienen estancado paliándolo añadiendo otro tipo de hardware complementario (memorias flash, más cores, etc).

Toda la memoria que necesites

La llegada de la tecnología “Memory Inception” permite que crear clusters de sistemas que compartan memoria entre ellos, pudiendo llegar a varios Petabytes de RAM disponibles para un mismo entorno dividido en varios servidores físicos. Con esto IBM se sitúa como líder en el desarrollo de tecnologías hardware para los clusters de aplicaciones sobre Red Hat OpenShift. En breve se anunciarán los servidores “medianos” de dos y cuatro sockets donde podremos seguir desplegando bien entornos mixtos de IBMi, AIX y Linux.

Encriptación “end-to-end”

No podemos finalizar este artículo sin mencionar una de las características claves de la plataforma IBM Power, que es la seguridad de los datos. Los nuevos procesadores incorporan cuatro veces más componentes de encriptación AES para anticipar las necesidades de los estándares criptográficos que llegarán desde 2022 como son las criptografía con seguridad cuántica o el cifrado totalmente homomórfico. Todo ello, aplicable a las nuevas cargas de trabajo basadas en contenedores donde la seguridad se ha convertido en la primera preocupación de las organizaciones que las utilizan.

AIX 7.3, UNIX más allá de 2030

Aunque dará para otro artículo, con la llegada de Power10 se anunciará la nueva versión de AIX, que será la 7.3, lo que no sucedía desde 2015. La numeración una cuestión de márketing. Si IBM hubiera optado por llamar a esta versión 8.1 hubiera quizás, generado dudas sobre si las novedades impactaban a la estabilidad para las aplicaciones existentes, pero como toda nueva versión incorpora muchas e interesantes nuevas funcionalidades. Hoy en día seguimos desplegando nuevos entornos en AIX, además de migrar otros desde Solaris, HP-UX e incluso Linux.

En todos nuestros grandes y medianos clientes existe una parte de sus entornos productivos donde se procesa la información que mantienen con vida sus negocios y procesos internos. ¿Dónde instalan Oracle, DB2, SAP, SAS, etc? En AIX. Ningún otro sistema operativo tipo UNIX ofrece la misma madurez, estabilidad, rendimiento y escalabilidad. Se trata de un UNIX moderno, con gran compatibilidad con aplicaciones modernas como Chef, Puppet, Ansible y que convive de maravilla con el resto de entornos basados en Linux, IBM i o Z/OS al que le queda mucha vida por delante y la nueva versión 7.3 es buena prueba de ello. Además tiene tres grandes ventajas para los departamentos y responsables de sistemas: todo funciona (vs esa sensación de hacer de beta-tester tan arraigada en Linux), corren sobre los servidores más estables y robustos que existen (excepción del Mainframe) y se aprende una sola vez, en lugar de cada vez que sale una nueva versión: todos recordamos ese momento donde el “ifconfig -a” dejó de funcionar en Red Hat :)

Tiempo de renovar equipos, licencias.. y de actualizar

Con la llegada de una nueva tecnología de procesadores, comienzan las “rebajas” en IBM. Si tenéis equipos Power7 o Power8 cuyos contratos de mantenimiento vayan a vencer (o incluso estén ya fuera de soporte) y os estéis planteando renovarlos o no contad con nuestra ayuda. Os asesoramos sobre como ahorrar mucho dinero con nuestros servicios de auditoría y renoviación de licencias, aprovechar al 100% los equipos IBM Power de los que disponéis y os ofrecemos a precio de coste nuevos servidores Power9 y en breve Power10.

¿Necesitas soporte técnico?

En Sixe Ingeniería ofrecemos soporte técnico y mantenimiento preventivo de AIX y Linux sobre Power Systems directamente y sin intermediarios. Estaremos encantados de ayudarte.

Aproveche el verdadero poder de CI/CD con Tekton y Kubernetes Pipelines

La introducción de las pipelines de Kubernetes (Tekton) ha supuesto una revolución en la forma de gestionar los flujos de trabajo de CI/CD en el desarrollo de software. La incorporación de Tekton a Kubernetes, nos ha dado más poder y flexibilidad en la creación y gestión de pipelines. Este artículo se centra en la importancia de Kubernetes Pipelines y Tekton en Red Hat OpenShift, y en cómo estas herramientas pueden ayudarte a que tu proceso de desarrollo sea realmente continuo.

¿Qué es una “pipeline”?

Una pipeline es un proceso automatizado que conduce el software a través de las etapas de construcción, prueba y despliegue del ciclo de vida del desarrollo de software. En otras palabras, una pipeline ejecuta el flujo de trabajo de Integración Continua y Entrega Continua (CI/CD). Gestiona automáticamente las tareas de ejecución del conjunto de pruebas, el análisis del código, la creación de binarios, la contenerización y el despliegue de los cambios en la nube o en las soluciones locales.

¿Por qué debería construir pipelines con Kubernetes?

A medida que el mundo del desarrollo avanza hacia la adopción de aplicaciones basadas en microservicios en lugar de aplicaciones monolíticas, el proceso de CI/CD se ha convertido en algo verdaderamente continuo con actualizaciones incrementales de la base de código que se pueden desplegar de forma independiente.

En un entorno así, Kubernetes simplifica el proceso de creación y mantenimiento de canalizaciones CI/CD. Despliega cada microservicio en un único clúster de Kubernetes y mantiene varias copias de cada microservicio para que sirvan como versiones de desarrollo, prueba y producción.

Con los pipelines de Kubernetes, ya no es necesario reconstruir toda la aplicación durante cada compilación. En su lugar, Kubernetes actualiza el contenedor del microservicio y lo despliega a través del pipeline definido. Ya no es necesario escribir scripts de compilación, ya que Kubernetes se encarga automáticamente del proceso con sólo unas pocas opciones de configuración que proporcionamos. Esto reduce la posibilidad de errores humanos en el flujo de trabajo de CI/CD.

¿Qué es Tekton?

Tekton le permite llevar los pipelines de Kubernetes al siguiente nivel. Es un marco de trabajo nativo de Kubernetes y de código abierto para el desarrollo de canalizaciones CI/CD. Tekton proporciona extensiones a las definiciones de recursos personalizadas (CRD) en Kubernetes para facilitar la creación y estandarización de canalizaciones. Tiene soporte incorporado para el acoplamiento con herramientas CI/CD existentes en la industria como Jenkins, Jenkins X, Skaffold, Knative y OpenShift.

La integración en OpenShift de Tekton, denominada OpenShift Pipelines, introduce aún más potencia y flexibilidad en este sistema a través de las herramientas para desarrolladores de RedHat y OpenShift.

¿Por qué debería utilizar Tekton?

Los pipelines de Tekton utilizan clusters de Kubernetes como tipo de primera clase y contenedores como sus principales bloques de construcción. La naturaleza desacoplada de Tekton garantiza que pueda utilizar una única canalización para desplegar en clústeres Kubernetes separados. Esto facilita el despliegue de servicios en múltiples soluciones en la nube suministradas por diferentes proveedores o incluso en sistemas locales.

Tekton permite ejecutar las tareas automatizadas de forma aislada, sin que se vean afectadas por otros procesos que se estén ejecutando en el mismo sistema. Otra especialidad de Tekton es la flexibilidad que proporciona para cambiar los recursos, como los repositorios de GitHub, entre las ejecuciones de la tubería.

También facilita el cambio de implementación de la tubería en función del tipo de recurso. Por ejemplo, puede configurar una implementación única para manejar imágenes.

Tekton acoplado a OpenShift garantiza una alta disponibilidad del sistema al permitir que cada unidad escale de forma independiente bajo demanda. Además, Kubernetes incorpora herramientas de registro y supervisión mejoradas y funciones de autorrecuperación rápida.

¿Cómo funciona Tekton?

Tekton proporciona CRDs al estilo de Kubernetes para declarar pipelines CI/CD. Los recursos se declaran en un yaml que, normalmente, se almacena con el repositorio de código. Vamos a considerar los CRD básicos que son esenciales a la hora de crear tuberías.

Tarea

Una Tarea es la unidad configurable más pequeña de una pipeline Tekton. Es similar a una función que acepta un conjunto de entradas y produce ciertos resultados. Cada tarea puede ejecutarse de forma individual e independiente o como parte de la cadena de producción. Un comando ejecutado por una Tarea se llama Paso. Cada tarea consta de uno o varios pasos. Tekton ejecuta cada tarea en su propio pod de Kubernetes.

Tubería (pipeline)

Una pipeline consiste en un número de tareas que forman el flujo de trabajo final automatizado de CI/CD. Además de las tareas, también contiene PipelineResources. Se proporcionan como entradas y salidas a las Tareas de la Red.

PipelineResource

Un PipelineResource es un objeto que se utiliza como entrada o salida de una Tarea. Por ejemplo, si la tarea acepta un repositorio de GitHub como entrada y construye y emite la imagen Docker relacionada, ambos se declaran como objetos PipelineResource.

PipelineRun

Un PipelineRun es una instancia de un Pipeline que se está ejecutando. Inicia la ejecución del Pipeline y gestiona los PipelineResources pasados a las Tareas como entradas y salidas.

TaskRun

Una TaskRun es una instancia en ejecución de una Tarea. PipelineRun crea objetos TaskRun para cada Tarea en el Pipeline para iniciar la ejecución.

Disparador

Un Trigger es un evento externo que desencadena el flujo de trabajo CI/CD. Por ejemplo, un pull request de Git podría actuar como un Trigger. La información transmitida con la carga útil del evento se utiliza entonces para activar las tareas en la canalización.

Condición

Las condiciones son similares a las sentencias if de la programación normal. Realizan una comprobación de validación con respecto a las condiciones proporcionadas y devuelven un valor Verdadero o Falso. El pipeline comprueba estas condiciones antes de ejecutar una tarea. Si la condición devuelve True, la tarea se ejecuta, y si devuelve False, la tarea se omite.

Con estos componentes, puede crear canalizaciones complejas y totalmente automatizadas para crear, probar e implantar sus aplicaciones en la nube o en soluciones locales.

¿Quién debe utilizar Tekton?

Los ingenieros de plataforma que construyen flujos de trabajo CI/CD para los desarrolladores de una organización encontrarán en Tekton un marco ideal para hacer este proceso más sencillo. Los desarrolladores también pueden crear flujos de trabajo CI/CD con Tekton para proyectos de desarrollo de software y aplicaciones. Esto les permite gestionar fácilmente las diferentes etapas del proceso de desarrollo, como las versiones de desarrollo, prueba y producción del producto, con una interferencia humana mínima.

¿Qué es lo siguiente?

Consulte la documentación oficial de Tekton y OpenShift Pipelines para obtener más información sobre cómo configurar pipelines de CI/CD que satisfagan las necesidades de su organización con facilidad.

¿Necesitas ayuda?

Ofrecemos Kubernetes y OpenShift formaciones y podemos ayudarle a comprar, desplegar y gestionar su
Entorno OpenShift en IBM Power Systems
.

Sixe Ingeniería
× ¡Hola! Bonjour! Hello!