Gestión de imágenes con Harbor en Tanzu
La gestión de imágenes para nuestros contenedores es una labor muy importante en el desarrollo y despliegue de nuestras aplicaciones. Normalmente cuando empezamos a trabajar con contenedores, usamos el registro público de Docker conocido como Docker Hub, pero a medida en la que avanza el proceso en nuestra organización buscamos poder tener mayor control sobre las imágenes, para garantizar que la imagen no presente vulnerabilidades, poder controlar el acceso a las mismas y otros aspectos que con Harbor podemos cubrir.
Harbor es una solución open source desarrollada por VMware y donada a la CNCF, así que si estás usando Tanzu puedes estar tranquilo, ya que Harbor cuenta con soporte directamente de VMware en caso de necesitarlo.
Algunos de los beneficios y características de Harbor son:
- Análisis de vulnerabilidades: Con Harbor podemos escanear o analizar nuestras imágenes en busca de vulnerabilidades, para esto Harbor usa el proyecto open source llamado Trivy.
- Gestión de usuarios: En Harbor manejamos nuestras imágenes a través de proyectos, sobre los cuales podemos dar o denegar accesos a nuestros usuarios o desarrolladores en caso de ser necesario. Adicionalmente, podemos integrarlo con nuestro Directorio Activo o usar usuarios locales.
- Configurar cuotas: Para tener un mejor control de nuestros recursos, en Harbor podemos establecer cuotas de almacenamiento para nuestros proyectos, con esto controlamos que por ejemplo un proyecto usado para almacenar imágenes de prueba no consuma el espacio de un proyecto de producción.
- Firma de imágenes: Firmar nuestras imágenes y verificar firmas es una forma de garantizar y verificar la integridad de las imágenes que usamos en nuestros despliegues, Harbor se integra con Notary para este propósito.
Para empezar a usar imágenes almacenadas en nuestra implementación de Harbor en nuestros despliegues debemos:
- Creamos un proyecto dentro de Harbor:
2. En nuestra máquina de Bootstrap debemos importar el certificado de Harbor. En este caso estamos usando certificados auto firmados, para obtenerlo tenemos dos opciones:
- Ejecutar el siguiente comando:
https://nombe_de_dominio_de_harbor/api/v2.0/systeminfo/getcert
- Desde la interfaz grafico de Harbor dando clic en la opción Registry Certificate:
3. Una vez tengamos el certificado de Harbor debemos guardarlo en la siguiente ruta:
- /etc/docker/certs.d/nombre_de_dominio_de_harbor/certificado_harbor.crt.
Si la ruta no existe previamente, debemos crearla:
- mkdir /etc/docker/certs.d/nombre_de_dominio_de_harbor/
4. Ahora ya podemos iniciar sesión en Harbor desde nuestra máquina de bootstrap, debemos usar las credenciales con las cuales nos logueamos en la interfaz gráfica de harbor, para esto usamos el siguiente comando:
- docker login nombre_de_dominio_de_harbor -u admin
5. Ahora podemos descargar la imagen a nuestra máquina:
- sudo docker pull nombre_de_imagen
6. Tagueamos la imagen descargada, por ejemplo wordpress:1.0
- docker tag wordpress:1.0 nombre_dominio_de_harbor/nombre_proyecto/wordpress:1.0
7. Insertamos la imagen en nuestro registro Harbor, para esto usamos el siguiente comando:
- docker push nombre_de_dominio_de_harbor /nombre_de_ proyecto/wordpress:1.0
Una vez tenemos nuestras imágenes en el registro de Harbor las podemos usar en nuestros despliegues, para ello solo basta con colocar la ruta de la imagen en el manifiesto yaml de nuestro deployment.
Gracias por leer.
¿Cómo se implementa un moodle?
Un moodle es implementado cuando un cliente solicita una plataforma educativa que permita a los docentes y estudiantes acceder a los recursos de manera más sencilla, y que cuente con foro, chats, tareas, cuestionario, etc.
Las plataformas web o sistema de gestión de contenido permiten realizar edición, desarrollo y administración de contenido diariamente, así como también, actualizaciones diarias, escribir artículos, crear páginas nuevas e insertar cualquier tipo de multimedia.
Adicionalmente, cuenta con soporte de actualizaciones y desarrollo de plugins, ya que moodle presenta una comunidad de software libre, la cual brinda seguridad ante cualquier inconveniente reportado para poder solucionarlo.
A continuación, se darán detalles de cómo realizar esta implementación de manera exitosa y también se indicará cuáles son los prerrequisitos para llevar a cabo esta actividad:
Para realizar esta actividad se debe contar con los siguientes prerrequisitos:
- Sistema operativo instalado Linux Debian 11 0 posterior
- Tener instalado el servicio de SSH y configurado para darse de manera remota desde cualquier equipo.
Paso 1: Acceso y actualización del sistema
Nota: Es recomendable contar con el usuario root o un usuario que permita instalar dependencias y servicios.
Previamente identificamos que se cuenta con un sistema operativo Debian versión 11 y procedemos a instalar las actualizaciones y realizar un upgrade de los paquetes y servicios a través del comando:
apt update && apt upgrade -y
Paso 2: instalar y configurar apache
Para cualquier tipo de gestor de contenido se requiere de un servicio web. Para tributación se utilizará apache y está instalada la siguiente manera:
apt install apache2 php -y
Para mejorar el máximo de conexiones permitidas se recomienda el parámetro de max_input_vars = 7000, que se encuentra en el archivo:
/etc/php/7.4/apache2/php.ini a 7000.
Usando el siguiente comando nano /etc/php/7.4/apache2/php.
Usando el comando control + x guardamos los cambios realizados.
Posteriormente reiniciamos el servicio utilizando el comando: systemctl restart apache2
Paso 3: instalar Maríadb
Moodle requiere de una base de datos para usuarios e información, por esto es recomendable instalar Maríadb, ya que se encuentra en los repositorios oficiales de Debian y se instala con el siguiente comando: apt install mariadb-server -y
Después de tener instalada esta base de datos, se procede a asegurarla y se realizará con los siguientes comandos:
mysql_secure_installation
Se recomienda asignar una contraseña que sea robusta.
Remover el usuario Anonymous:
Remover la base de datos de prueba.
Aplicar cambios sobre la configuración.
Luego, se procede a crear una base de datos donde se almacenará moodle y los usuarios con los siguientes comandos:
- mysql -u root -p acceder con la contraseña previamente creada
2. Crear base de datos Moodle usando CREATE DATABASE moodle_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;;
3. Crear usuario Moodle en la base de datos mysql usando CREATE USER moodle_user@’localhost’ IDENTIFIED BY ‘m0d1fyth15’;
3. Asignar privilegios al usuario y base de datos usando GRANT ALL on moodle_db.* to moodle_user@localhost;
4. Aplicar cambios usando FLUSH PRIVILEGES;
5. Salir usando \q
Paso 4: Instalar PHP
Cualquier contenido web requiere del uso de php, para esto se instalan todas las extensiones de php a través del comando:
apt install php libapache2-mod-php php-iconv php-intl php-soap php-zip php-curl php-mbstring php-mysql php-gd php-xml php-pspell php-json php-xmlrpc -y
Paso 5: Descargar Moodle
- Ahora se descargará la versión estable de moodle desde su sitio oficial https://download.moodle.org/releases/latest/ utilizando el comando wget https://download.moodle.org/download.php/direct/stable400/moodle-4.0.1.zip
2. Extraer el archivo usando un zip que previamente debe estar instalado (apt install unzip -y) y enviarlo a la carpeta que se encuentra en /var/www/html/ usando el siguiente comando:
unzip moodle-4.0.1.zip -d /var/www/html/
3. Crear el directorio con: mkdir /var/www/html/moodledata
4. Asignar permisos a los directorios y reencontrar en apache usando los siguientes comandos:
chown -R www-data:www-data /var/www/
chown -R www-data:www-data /var/www/html/moodle/
chmod -R 755 /var/www/html/moodle/
chown -R www-data:www-data /var/www/html/moodledata/
5. Por último, procedemos a instalar el moodle de manera web
Accediendo a http://192.168.1.29/moodle/install.php
Dar click en siguiente.
Configurar la url brindar los datos indicados.
Configurar la base de datos utilizando MaríaDB.
Suministrar la información de la base de datos configurada y dar en siguiente.
Y en la ruta configurar el parámetro $CFG->dbtype y agregar ‘mariadb’;//’mysqli’;
Por último, reiniciar el servicio de apache
/etc/init.d/apache2 restart
Aceptar las condiciones y dar click en siguiente.
Comprobar que cumpla con los requerimientos solicitados y dar clic en continuar.
Diligenciar los datos acerca de los datos del perfil y dar clic en actualizar perfil.
Después de realizar estos ajustes, finalizamos la instalación y accedemos a un dashboard como administrador
Gracias por leer.
Hecho por: Oscar Gonzalez
Editado por: Diana Oviedo
Referencias
CHECK VSAN HEALTH
Es de conocimiento general que la administración de VMware vSAN se realiza por medio del vCenter Server, pero existen situaciones donde no es posible acceder a la GUI del vCenter Server por diferentes motivos:
- vCenter off line: El vCenter server se encuentra fuera de línea por razones de mantenimiento o falla interna.
- Migraciones dispositivos de red: En el data center se están realizando migraciones a nivel de dispositivos de red, lo cual implica que se pierda conectividad con el vCenter.
En la actualidad muchos clientes corren soluciones críticas en VMware vSAN y por tanto no se pueden dar el lujo de desconocer el estado de salud de dicha plataforma. En ese orden de ideas, hay una buena noticia y es que VMware vSAN es completamente funcional si el vCenter server se encuentra fuera de línea, ya que la administración de la vSAN se realiza por medio de la interfaces de comando de los ESXi´s.
Con vista en lo anterior, el objetivo de este manual es compartir la forma de realizar la validación del estado de salud de la vSAN, por medio de la línea de comandos.
Paso 1: Conectarse a un ESXi por SSH con credenciales de root.
En este paso, es importante habilitar previamente el servicio SSH en el ESXi, lo cual se hace desde la pestaña Configure>Services, luego seleccionamos SSH y damos clic en la parte superior en START.
En la siguiente imagen se detalla el paso a paso:
Paso 2: Luego de conectarnos al ESXi, validamos el estado de salud de la vSAN ejecutando el siguiente comando:
esxcli vsan health cluster list
Este comando es similar al Skyline Health que se corre desde el vCenter Server y nos permite conocer cómo se encuentra la vSAN en los siguientes niveles:
- Overall
- Cluster
- Network
- Data
- Capacity Utilization
- Physical disk
- Performance services.
En términos generales, cuando la vSAN se encuentra sana, todos los valores deben estar en green exactamente como se muestra en la siguiente imagen:
Paso 2: Luego de conectarnos al ESXi, validamos el estado de salud de la vSAN ejecutando el siguiente comando:
esxcli vsan health cluster list
Este comando es similar al Skyline Health que se corre desde el vCenter Server y nos permite conocer cómo se encuentra la vSAN en los siguientes niveles:
- Overall
- Cluster
- Network
- Data
- Capacity Utilization
- Physical disk
- Performance services.
En términos generales, cuando la vSAN se encuentra sana, todos los valores deben estar en green exactamente como se muestra en la siguiente imagen:
Paso 3: Revisar el estado de salud de los objetos vSAN, lo cual nos permite conocer cómo se encuentran y si hay objetos inaccesibles. Para ello ejecutamos el siguiente comando:
esxcli vsan debug object health summary get
Es importante resaltar que todos los valores de la salida del comando deben estar en cero. En la siguiente imagen se muestra un ejemplo real, donde se aprecia que hay cero objetos inaccesibles, lo cual indica que a nivel de objetos la vSAN se encuentra sana:
Paso 4: Revisar la comunicación con los otros miembros de la vSAN. Este paso es de gran importancia, porque nos permite identificar si se presentan fallas en la comunicación con algún ESXi. El comando a ejecutar es el siguiente:
esxcli network ip neighbor list
La salida del comando nos debe listar todas las Mac Address de los vmknic de cada ESXi y el tipo debe ser Dynamic.
En la siguiente imagen se muestra un ejemplo:
Es importante aclarar que si en la columna Mac Address sale Incomplete y en Type sale Invalid, eso quiere decir que ese host tiene problemas de comunicación.
Paso 5: Comprobar comunicación con el vmk de vSAN. Este paso nos sirve para validar cómo se encuentra la comunicación a nivel del vmk designado de forma exclusiva para vSAN. Para ello es importante conocer previamente cuál es el vmk designado para vSAN. El comando a correr es el siguiente:
esxcli network ip neighbor list -i vmk2 (vmk de vsan)
La salida de este comando nos debe arrojar la IP, la Mac Address, el Vmknic y el type para cada uno de los ESXi´s que hacen parte del clúster de vSAN.
En la siguiente ilustración se muestra un ejemplo:
Paso 6: Comprobar comunicación con un miembro específico de la vSAN. Este paso nos sirve para validar la comunicación con un miembro en particular de la vSAN y cada uno de sus vmk. Es decir, podemos revisar el vmk1, el vmk2, el vmk3 y los otros que tenga dicho ESXi. El comando a ejecutar es el siguiente:
vmkping -I vmk2 XXdestinoXX -s -d
Donde la opción -d es para utilizar el bit Dont´t Fragmente en IPV4.
La opción -s es para indicar el tamaño del MTU utilizado en ESXi.
En la siguiente imagen se puede observar la salida de dicho comando (se aclara que se está revisando la comunicación por medio del vmk1):
Ejemplo con vSAN particionada
A continuación, se detalla un escenario en el que la VMware vSAN se encuentra particionada.
Paso 1: Luego de ingresar por SSH al host, ejecutamos el comando
esxcli vsan health cluster list y encontramos que a nivel general se presenta un problema de networking, y el clúster se particionó.
En la siguiente imagen se puede observar el detalle de la falla reportada:
esxcli vsan health cluster list
El comando anterior nos indica que el clúster está particionado, entonces continuamos haciendo throubleshooting y ejecutamos el siguiente comando:
esxcli vsan health cluster get -t “vSAN cluster partition”
El comando anterior nos permite identificar cuales hosts se encuentran particionados, es decir que no tienen comunicación a nivel de vSAN.
En la siguiente ilustración se aprecia que el host cuya IP es 172.20.10.53 se encuentra particionado, es decir, aislado de los demás miembros de la vSAN por fallas de red:
Paso 2: Luego ejecutamos el comando esxcli vsan debug object health summary get
y obtenemos que hay 8 objetos inaccesibles lo que indica que NO se puede tener acceso a los mismos que se encuentran en el datastore de vSAN.
En la siguiente imagen se detalla el mensaje:
Paso 3: Revisar la comunicación con los otros miembros de la vSAN ejecutando el siguiente comando esxcli network ip neighbor list y encontramos que hay un host con problemas de comunicación.
En la siguiente imagen se detallan los errores:
En conclusión, conocer cómo revisar el estado de salud de VMware vSAN por medio de la línea de comando es de gran importancia porque nos ayuda a identificar en tiempo real como se encuentra dicha plataforma y además es de gran utilidad cuando se presentan fallas con el vCenter Server.
Tipos de migraciones utilizando VMware
La virtualización se ha convertido en una de las herramientas más utilizadas por las empresas para gestionar sus recursos informáticos. VMware es uno de los proveedores más populares de soluciones de virtualización, ofreciendo una amplia gama de herramientas que permiten a los usuarios migrar fácilmente entre diferentes entornos de virtualización.
Hay varios tipos de migraciones disponibles en VMware, cada uno con sus propias características y beneficios. A continuación, describimos los diferentes tipos de migraciones disponibles:
1). vMotion: esta es una migración en vivo que permite a los usuarios mover máquinas virtuales de un servidor a otro sin interrupciones, lo que significa que las aplicaciones y servicios continuarán funcionando sin problemas. vMotion funciona al mover el estado de la máquina virtual de un servidor a otro, sin mover los datos de almacenamiento, esto hace que el proceso sea rápido y no requiere una gran cantidad de ancho de banda.
2). Storage vMotion: es una herramienta útil para el equilibrio de cargas, la migración de datos entre diferentes discos duros, el cambio de ubicaciones de discos duros y la consolidación de datos.
3). Cross vCenter vMotion: Esta migración es útil cuando se necesita migrar una máquina virtual de un centro de datos a otro.
4). Cold Migration: esta migración implica apagar la máquina virtual antes de hacerla migrar. Con la migración en frío, el sistema detendrá la máquina virtual, migrará los datos y luego iniciará la máquina virtual en el nuevo servidor. Esta migración es útil para trasladar máquinas virtuales grandes o máquinas virtuales con recursos de hardware limitados.
5). VMware Converter: Esta es una herramienta de migración que permite a los usuarios convertir máquinas físicas en máquinas virtuales o migrar máquinas virtuales de una solución de virtualización a otra con diferentes soluciones de virtualización.
VMware HCX es una plataforma de movilidad de aplicaciones que permite a los usuarios migrar cargas de trabajo entre diferentes entornos de nube, regiones y centros de datos.
HCX proporciona a los usuarios una plataforma de migración de aplicaciones de extremo a extremo, que incluye desde la planificación y la preparación hasta la migración en sí. Además, ofrece una gama de herramientas de migración que incluyen vMotion, Cold Migration y Bulk Migration, lo que permite a los usuarios migrar fácilmente sus cargas de trabajo desde y hacia diferentes entornos de nube.
Con HCX se pueden realizar diferentes tipos de migraciones, entre los que se incluyen:
- Migraciones en caliente (vMotion): Permite migrar una máquina virtual en ejecución entre diferentes centros de datos, sin interrupción de servicio.
- Migraciones en frío: Permite migrar una máquina virtual apagada entre diferentes centros de datos.
- Migraciones de almacenamiento: Permite migrar el almacenamiento de una máquina virtual entre diferentes entornos de almacenamiento.
En conclusión, VMware ofrece una variedad de herramientas de migración que permiten a los usuarios mover fácilmente sus máquinas virtuales entre diferentes entornos de virtualización. La elección de la herramienta de migración adecuada dependerá de los requisitos específicos de cada usuario.
Gracias por leer.
Blog hecho por: Nicolás Rodríguez
Editado por: Diana Oviedo
DESPLIEGUE NSX-T ADVANCE LOAD BALANCER
Para iniciar a realizar la migración de tecnología de NSX-V a NSX-A se deben tener en cuenta varias cosas:
Descarga de la OVA
- Revisar qué versión de NSX-T maneja el cliente. De acuerdo con ello, se puede ver en la página https://interopmatrix.vmware.com/ qué versión es compatible con AVI para proceder a hacer la descargar correspondiente de la OVA.
- Luego de saber qué versión nos sirve vamos a la página https://customerconnect.vmware.com/downloads/#all_products donde descargaremos la OVA
- Estando allí, buscamos VMware NSX Advanced Load Balancer
- Vamos a la parte de descarga y allí seleccionaremos la versión requerida. Una vez se haya seleccionado esta opción procedemos a descargar la OVA
Configuración de controladores y SE
- Luego de la descarga de la OVA es importante haber definido la zona de transporte en NSX-T
- Se debe contar con un segmento o IP´s de administración para los 3 controladores y los N Service Engine que vamos a desplegar. Esto con el fin de lograr comunicación entre los controladores y los SE
- La siguiente tabla será a modo ejemplo:
- Hay que asegurar que estén permitidos los puertos 123, 443, 8443 y 22 para comunicación entre los SE y los controladores
- Se debe tener en cuenta la licencia que se va a instalar en el cliente, ya que de esa forma sabremos como se habilitarán los modos de HA dispuestos por AVI, esta será la forma en cómo los SE´s van a trabajar (Active/Standby, Elastic N+M y Active/Active)
- También se tendrán en cuenta cuántos Virtual Services tiene el cliente, de esta forma saber cómo crecer a nivel de recursos sacando un detalle aproximado como lo muestra la siguiente imagen:
Despliegue de los Controladores de AVI
Se realizará el paso a paso
- Despliegue de la OVA
2. Se desplegará la siguiente imagen donde seleccionaremos el lugar donde guardamos la OVA
3. Acá Seleccionaremos el lugar donde crearemos nuestros Controladores y el nombre que le asignamos
4. En esta opción seleccionaremos en que parte de V-Sphere queremos que se vean nuestros controladores al momento de realizar el despliegue
5. En esta parte seleccionaremos el formato que se usará para reservar los recursos del controlador y cuál disco se almacenará, si se cuenta con más de uno
6. Seleccionaremos la red de administración, para nuestro caso es la 10.10.10.X
- Aquí debemos llenar los siguientes ítems de acuerdo con la construcción que tenemos en la tabla. Después de completar los campos damos siguiente y finalizar
- Debemos repetir lo anterior 2 veces más de acuerdo con la información del documento para tener nuestros 3 controllers configurados como se muestra en la siguiente imagen:
9. Una vez estén creados los Controladores procederemos a encenderlos uno a uno
10. Esperamos alrededor de 2 a 3 minutos mientras el sistema termina de configurar y encender los controladores. Al cabo de ese tiempo, abrimos un navegador donde ingresaremos a nuestro primer controlador de la siguiente manera:
Cuando nos abra la página, crearemos una contraseña y agregaremos nuestro correo.
- Una vez ingresemos nos pedirá lo siguiente: debemos crear una Passphrase que será para encriptar la información y en caso de respaldo la tendremos que usar
12. Si contamos con un servidor de SMTP lo configuramos. En caso de no tener en el momento, le damos clic en “none” y luego en siguiente
13. En esta opción nos va a indicar si AVI tendrá más de un Tenant o no. Para efectos del ejemplo será un solo Tenant y marcamos la casilla de selección “setup cloud after”.
Para mas información consular en: https://avinetworks.com/docs/22.1/installing-avi-vantage-for-vmware-vcenter/
- Tan pronto demos guardar ya nos mostrará el entorno AVI
15. Una vez estando en AVI lo que haremos es cargar la licencia: Administration>Settings>licensing
16. Para agregar la licencia damos clic en el engrane y se abrirá otra pantalla donde debemos seleccionar el tipo de licencia que tenemos. Una vez seleccionado damos guardar.
- Paso seguido escribimos la licencia, damos aplicar llave y nos mostrara un mensaje de licencia exitosa.
18. Una vez agregada la licencia nos aparecerá la cantidad de SE que posee esa licencia y la fecha de expiración de esta
- En el siguiente paso conformaremos el clúster de los controladores nos dirigiremos a las siguientes opciones administration>Controller>Nodes, nos aparecerá la Ip de nuestro primer controlador. Daremos clic en editar
20. Acá pondremos el nombre del clúster y la IP
21. Luego en la parte de abajo editaremos y agregaremos de la misma manera los demás controladores
Nota: Si se presentan problemas al momento del despliegue de los SE, no incluir los DNS en esta opción, ya que esto solo funcionara en una solución Cloud
Luego damos guardar
- Una vez guardado nos aparecerá el rol que tomará cada controlador, uno será el líder y los otros dos seguidores
De esta manera ya hemos configurado AVI, lo siguiente es configurar los SE y los VS para los diferentes aplicativos.
Gracias por leer.
Autor: Jonathan Gutiérrez
COMPARTE ESTE POST
La regla de backup 3-2-1 de Veeam
La regla 3-2-1 es muy general y funciona para todo tipo de datos (individuales y corporativos) en entornos físicos y virtuales.
Al realizar la regla en copias de backup de entornos VMware o Hyper-V con Veeam, se convierte en la “regla de backup 3-2-1-0”, en la que 0 significa “0 errores” durante la verificación automática de la recuperabilidad de cada backup con SureBackup de Veeam.
Veeam Backup & Replication puede ayudarlo a cumplir con todos los requisitos de la regla de backup 3-2-1:
- Tener al menos tres copias de sus datos: configure trabajos de backup para crear varias copias de cada una de sus VM de VMware o Hyper-V.
- Almacenar las copias en dos medios diferentes: Veeam es un almacenamiento agnóstico, lo que significa que es compatible con cintas, discos, la nube y más. Puede almacenar sus copias de backup en cualquiera de los medios enumerados.
- Tener una copia de backup en un medio externo: configure trabajos de copias de backup para transferirlas más rápido a un medio externo con la Aceleración WAN integrada o utilice Veeam Cloud Connect para almacenar copias de backup en un medio externo en una infraestructura de proveedor de servicios.
La Regla 3-2-1 nos ayudará a tener más conciencia sobre la importancia que tienen los respaldos de los ambientes productivos ante un desastre.
Los objetivos de recuperación de ambientes productivos ante un desastre
El tiempo de inactividad no es una opción para las organizaciones modernas que deben satisfacer las necesidades y expectativas de sus clientes. Se pueden producir varios incidentes que tengan un impacto en los ingresos de su negocio o incluso en su existencia, ya sea un ataque de ransomware, un corte de energía, una inundación o simplemente errores humanos, estos eventos son impredecibles y lo mejor que puede hacer es estar preparado.
Estar preparado significa que debe tener un plan sólido de Continuidad Comercial y Recuperación ante Desastres (BCDR, por sus siglas en inglés). Uno que haya sido probado y pueda ponerse en marcha sin problemas.
Dos de los parámetros importantes que definen un plan BCDR son el Objetivo del Punto de Recuperación (RPO, por sus siglas en inglés) y el Objetivo del Tiempo de Recuperación (RTO, por sus siglas en inglés). Para quienes no están familiarizados con estos términos, permítanme darles una breve descripción:
- RPO limita la distancia de retroceso en el tiempo y define la cantidad máxima permitida de datos perdidos desde la ocurrencia de una falla, hasta la última de backup válida.
- RTO está relacionado con el tiempo de inactividad y representa cuánto se tarda la restauración desde el incidente hasta que las operaciones normales estén disponibles para los usuarios.
Si bien RPO y RTO pueden parecer similares, sirven para diferentes propósitos y en un mundo ideal, sus valores serían tan cercanos a cero como sea posible. Sin embargo, de vuelta en nuestro mundo, el costo cero para RPO y RTO sería extremadamente costoso y podría no valer la pena el esfuerzo.
Cómo definir los valores de RTO y RPO para sus aplicaciones
A razón de que las empresas son diferentes y tienen distintas necesidades, no existe una solución única para un plan de continuidad del negocio y sus métricas, por lo tanto, tienen diferentes requisitos para sus objetivos de recuperación. Sin embargo, una práctica común es dividir aplicaciones y servicios en diferentes niveles, así como establecer los Valores de Tiempo de Recuperación y Objetivo (RTPO, por sus siglas en inglés) de acuerdo con los Acuerdos de Niveles de Servicio (SLA, por sus siglas en inglés), con los que se compromete la organización.
La clasificación de protección de datos es importante para determinar cómo almacenar, acceder, proteger, recuperar y actualizar datos e información de manera más eficiente en función de sus criterios específicos. Es de suma importancia analizar sus aplicaciones y determinar cuáles de ellas están impulsando su negocio, generando ingresos y siendo imprescindibles para mantenerse operativo. Este proceso, que es esencial para un buen plan de continuidad comercial, se denomina Análisis de Impacto del Negocio (BIA, por sus siglas en inglés), que establece protocolos y acciones para enfrentar un desastre. Por ejemplo, puede usar un modelo de tres niveles para diseñar su plan de continuidad del negocio:
- Nivel 1: Aplicaciones esenciales que requieren un RTPO de menos de 15 minutos.
- Nivel 2: Aplicaciones esenciales para un negocio que requieren RTO de 2 horas y RPO de 4 horas.
- Nivel 3: Aplicaciones no esenciales que requieren RTO de 4 horas y RPO de 24 horas.
Es importante tener en cuenta que las aplicaciones esenciales, para un negocio y las no esenciales, varían de una industria a otra, y cada organización define estos niveles en función de sus operaciones y requisitos.
Autor:
Jesús Daniel Montes Ramirez
Allure availability skirt artificial extra ordinary jewelry. Modification petticoat jersey hanger buttons influence proportion. Imprint accessory imagination attractive impeccable.
Halter bold radical breathable. Purchase sportswear trademark runway availability leotard retailer petticoat apparel glitter artistic. Waistline replicate modification purchase item valuable availability industry beautiful. Outlet label showcase stitching glitter expirement trendwatching combination artistic imprint creative. Zipper pattern bargain jersey artistic make up allure skirt.
Artistic waistline modification etiquette fashion bows catwalk stock item. Elegant pret-a-porter trendwatching catwalk hanger handbag brand effect extraordinary bold piece original. Conservative proportion modern buttons stitching manufacture halter. Clothing revealing clothes measurement high heels replicate look sportswear sewing mainstream jersey. Ensemble retailer apron quality identity imprint hanger glitter. Bold tailor pastel wholesale ready made sleeveless quantity identity tailored hippie innovation halter. Conservative brand illustration value jeans price model expensive. Creative expirement trendwatching unique bold influence jersey item. Jersey hand-made photography enhance. Halter ensemble motif etiquette allure.
Edge accessory skirt. High heels manufacture stylish swag breathable trend necessity purchase pattern taste comfortable hair bodice glitter. Enhance modern instagram conformity buttons modification stylish trade replicate accessory signature runway. Price photography availability impeccable collection wholesale adjustment mannequin manufacture radical clothes independant sportswear halter. Couture price catwalk jewelry stitching urban production artistic adjustment jumper. Hippie textile pumps limited hand-made urban make up revealing. Hair inspiration popular comfortable trendwatching. Waistline xl mode independant outfit bows. Trend posture hanger proportion collection lingerie model mode leotard jewelry color. Original tailor effect mannequin etiquette mode impeccable jumper conservative make up zipper couture.
Brand jewelry outfit expirement waistline. Modification make up condition. Bold contemporary value casual mainstream purse motif hair pumps purchase urban Haute-couture pastel. Classic waistline mode accessory extraordinary. Availability prediction jersey breathable phenomenon price expirement pumps trade. Original taste wholesale sleeveless. Retailer halter swag. Tailored piece outlet apron necessity adjustment posture shawl fashion original handbag. Luxurious minimalist sleeveless trend commercial garment xl. Handbag allure photography hair proportion.
Comfortable swim-wear valuable photography artificial runway illustration petticoat jacket pastel artistry classic xs. Urban pumps clothing Haute-couture instagram imprint. Etiquette xs beautiful. Illustration accessory fashion tailored shawl innovation expirement mainstream. Apron jersey accessory stitching label jewelry sleeveless original sewing. Lingerie clothing catwalk buttons commercial stock affection motif. Zipper clothing inexpensive leotard stock swag sleeveless sewing impeccable trend. Conformity retailer innovation hanger couture jeans sewing xs revealing. Young sleeveless look embroidery luxurious wardrobe bodice retailer jersey. Pret-a-porter lingerie mode clothing sleeveless old-fashioned unique.
¿Cómo convertir Máquina virtual Citrix a VMware?
Muchas veces nos encontramos con algunos servicios o aplicaciones que viven en diferentes soluciones de virtualización, una de las más comunes es Citrix Xenserver. Cuando se adquiere o implementa VMware para solución de virtualización en el centro de datos, se requiere migrar estos servicios, bien sea por homologar la infraestructura, aprovechar al máximo nuevas funcionalidad o simplemente por temas de licenciamiento.
A continuación, se detalla cómo podemos migrar exitosamente una máquina virtual que vive en una infraestructura de Citrix Xenserver a una infraestructura VMware vSphere.
Antes de poder iniciar la conversión es fundamental desinstalar las herramientas de Citrix en la máquina virtual.
- Agente invitado de Citrix XenServer Windows
- Proveedor Citrix XenServer VSS
- Proveedor de herramientas Citrix XenServer
- Controlador Citrix Xen Windows x64 PV
Al desinstalar las herramientas se perderá la conexión de red de la máquina virtual, se debe reiniciar el OS desde la consola de XenCenter. Este reinicio puede ejecutarse más de una vez si es necesario hasta que se establezca la conexión a la red.
- Inicie sesión en su máquina donde desee realizar las tareas de migración, puede ser su máquina local o crear una máquina virtual dedicada
- Inicie el asistente de VMware vCenter Converter Standalone (Puede Instalar o actualizar a la última versión liberada 6.3.0)
3. Para el origen Haga clic en convertir máquina virtual e ingrese las credenciales de administrador local de la máquina que desea migrar.
4. Haga clic en sí para desinstalar de forma automática los archivos una vez la migración se realice de manera exitosa.
5. Para el destino seleccione VMware Infraestructure virtual machine. Ingrese las credenciales del administrador local del vCenter destino
Nota. Si la máquina que desea migrar no tiene acceso directo al servidor de destino puede habilitar el Proxy mode para realizar la conversión.
6. Ignore el certificado remoto y continúe con el siguiente paso.
7. Seleccione la ubicación de la máquina virtual en el destino (Recursos de cómputo y Almacenamiento).
8. Puede configurar algunos parámetros para la tarea de conversión si lo desea, de lo contrario deje todos por defecto y continúe.
9. Revise el resumen de la tarea de conversión, si todo está correcto dé clic en finalizar.
10. A continuación, podrá ver el estado y el progreso de todas las migraciones que se encuentran en curso, el tiempo de ejecución puede varios dependiendo del tamaño de los discos de la máquina virtual.
Una vez completada la migración podrá apagar la máquina virtual desde XenCenter y proceder a encenderla en el lado de VMware.
Por último, inicie sesión en la máquina virtual migrada en VMware e instale las VMware Tools, Montara el ISO en la máquina virtual. Realice la instalación y reinicie el OS.
Después conecte la máquina a la red deseada y configure los parámetros de red de forma manual (IP, Gateway y DNS).
Una vez la máquina virtual esté operativa puede monitorear su comportamiento y los servicios {que se ejecutan.
Recomendación
De forma predeterminada VMware vCenter Converter Standalone trae la encriptación del tráfico habilitada. Cuando programe varias tareas de migración en paralelo puede deshabilitar la encriptación SSL para aumentar la tasa de transferencia de datos.
Windows versions – %ALLUSERSPROFILE%Application DataVMwareVMware vCenter Converter Standalone
Open the converter-worker.xml file using a text editor.
Locate the tag pair <useSsl></useSsl>. It is located inside the <nfc> tag and has a value of true.
Change the value to false.
Save and close the file.
Restart the VMware vCenter Converter Standalone Worker service on the machine.
Restart the VMware vCenter Converter Standalone Worker service on the machine.
Con esto concluimos la tarea de migración de un server en un entorno Citrix a uno de VMware.
Esperamos sea de gran ayuda.
Referencias:
https://community.spiceworks.com/how_to/126530-migrating-a-citrix-xenserver-vm-to-vmware
https://blog.migrationking.com/2019/11/how-to-speed-up-vmware-converter-62.html
https://kb.vmware.com/s/article/1004588
Escrito por: Jefferson Camargo (Consultant)
Edición por: Diana Oviedo (Marketing digital)
NSX Intelligence
NSX Intelligence – Cómo desplegar NSX Intelligence
NSX intelligence es un componente adicional dentro del entorno de NSX Data Center y la virtualización de redes. Este gestiona, permite realizar un análisis a la red y administra de manera más optima todo el flujo de tráfico que se presenta dentro de la infraestructura, para que el administrador tenga la capacidad de acceder a recomendaciones que NSX intelligence ofrece, con el fin de mejorar la seguridad y denegar comunicaciones que no deberían presentarse entre las maquinas.
¿De qué manera funciona NSX Intelligence?
NSX intelligence recopila información desde los NSX mánager y los actualiza cada 5 minutos, lo que le permite aprender el funcionamiento del tráfico de las diferentes aplicaciones que se presentan. Una vez analiza este flujo de datos, genera ciertas recomendaciones para que sean aplicadas por medio de reglas hacia el firewall.
De igual manera, para que el entorno permanezca en óptimas condiciones y seguro, NSX intelligence permite a un administrador generar una planificación para la microsegmentación y con esto se producen recomendaciones para las reglas, grupos y servicios del firewall. Hay que tener en cuenta que para desplegar NSX intelligence es de gran importancia contar con el licenciamiento adecuado, en lo posible, Enterprise plus, debido a que es el licenciamiento que soporta dicho componente.
¿Cómo desplegar NSX Intelligence?
PASO 1
Una vez se tenga desplegado VSphere y los 3 nodos de NSX, vamos a ir a:
System -> appliance
Bajamos hasta la parte de NSX Intelligence Appliance y vamos a seleccionar la siguiente opción:
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-1.jpg\")
Figura 1. (ADD NSX INTELLIGENCE APPLIANCE)
PASO 2
Una vez hayamos dado clic en el recuadro, se abrirá un wizard para empezar con el despliegue del NSX intelligence
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-2.jpg\")
Figura 2. (Selección de appliance)
Vamos a dar clic en SELECT y elegimos el appliance que descargaremos en el siguiente link: https://customerconnect.vmware.com/downloads/info/slug/networking_security/vmware_nsx_intelligence/1_x
IMPORTANTE: luego de seleccionar el appliance también debemos darle a UPLOAD para que empiece a subir y poder continuar con el deploy.
PASO 3
Continuamos brindando la información restante que el Wizard nos solicita el cual es:
- Hostname o FQDN: nsxint-01.dominio.com
- IP de gestión y mascara: ejemplo 198.268.0.10/24
- Puerta de enlace de gestión: ejemplo 192.168.0.1
- Servidores DNS: ejemplo 8.8.8.8 y 4.4.4.4
- Servidores NTP: ejemplo 8.8.8.8 y 4.4.4.4
- Tamaño del NSX intelligence: small o Large
- Small es usado para entorno de prueba o pequeños
- Large es usado para entornos de producción o grandes.
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-3.jpg\")
Figura 3. (información de red para el appliance)
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-4.jpg\")
Figura 4. (información de red para el appliance)
Una vez digitemos la información que nos sea solicitada. Vamos a darle a NEXT.
PASO 4
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-5.jpg\")
Figura 5. (configuración del appliance)
La sección 2 de configuración del appliance nos va a solicitar lo siguiente:
- Compute Manager: debió haberse configurado previamente en los NSX manager y es de donde va a recopilar la data
- Compute cluster: es de donde va a tomar el pool de recursos, tanto CPU como RAM y así funcionar correctamente. (Si hay un cluster de gestión, debería ir allí)
- Host: es el host donde va a tomar los recursos, sin embargo, debería dejarse sin host para que el mismo decida el mejor y más adecuado para funcionar
- Data Store: donde se va a tomar recursos de almacenamiento
- Virtual Disk Format: es el formato de disco el cual va a utilizar
- Thin Provisionin
- Thick Lazy Zeroed
- Thick Eager Zeroed
- Network: es el port group que va a utilizar, (debe asignar el port group de administración.
Por último, vamos a dar clic en NEXT.
PASO 5
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-6.jpg\")
Figura 6. (Credenciales del appliance)
En este paso solo elegiremos la contraseña que queremos usar en el appliance, que son:
- Root
- Admin
- Audit
Una vez terminemos de asignar las contraseñas, vamos a darle install appliance.
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-7.jpg\")
Figura 7. (Credenciales del appliance)
Luego de dar clic al último paso, procede a instalar como vemos en la figura 8:
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-8.jpg\")
Figura 8. (Instalación del appliance)
Por ahora solo queda esperar, puede tardar varios minutos o incluso horas, por lo que una vez se termine de instalar, se debe configurar, y esto mostrará un estado de alerta de estado del servicio degradado; sin embargo, permanecerá así por unas cuantas horas mientras termina de configurarse y recopilar la información necesaria.
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2022/10/IMAGE-9.jpg\")
Figura 9. (finalización del deploy NSX INT)
Para poder desplegar de manera correcta hay que tener varias cosas en cuenta:
- El servicio NTP debe estar corriendo y funcionando en todos los hosts de manera correcta
- El licenciamiento debe ser Enterprise plus
- El NSX intelligence debe estar ubicado en el port group de administración o poder ver los demás appliance de gestión para que funcione correctamente
- En lo posible ubicarlo en un cluster de gestión si lo hay
- Disponer de los recursos de hardware para que funcione de manera óptima.
Deseamos que este artículo le haya sido de gran utilidad!
Escrito por:
Juan Diego Jiménez
Consultor Junior – V2S
COMPARTE ESTE POST
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on print
Share on email
![\"\"](\"https://portfolio.v2s.us/wp-content/uploads/2020/09/logo-V2S-V.png\"){kind=logo}
Fundada en 2006, V2S Corporation es una multinacional de Servicios de Infraestructura y Aplicaciones para todos los sectores e industrias.
Somos expertos en soluciones innovadoras de Virtualización como respuesta a los retos actuales de Transformación Digital.
Nuestras soluciones personalizadas y el conocimiento de los distintos sectores son nuestros principales diferenciadores. Llevamos años auditando, diseñando, implementando y gestionando las soluciones de virtualización más avanzadas. Nuestros servicios se enmarcan dentro del profesionalismo, la precisión, la innovación y la calidad.
V2S Corporation opera globalmente desarrollando proyectos en distintos países. Tenemos oficinas y personal en Europa, África y América Latina. Aunque nuestras operaciones están muy extendidas, nuestro enfoque es operar como una empresa multinacional global centrada en la calidad del servicio. La misma metodología y enfoque están presentes allí donde ofrecemos nuestros servicios adaptándonos al mismo tiempo, a los retos locales.
Habla con nuestros expertos
Actualización de vSphere de 6.7 a 7u3
Actualización de vSphere de 6.7 a 7u3
- BLOG
- julio 19, 2022
Actualización de vSphere de 6.7 a 7u3: todo lo que necesita saber en un solo lugar
Las actualizaciones de los productos VMware aseguran un apropiado funcionamiento y soporte durante el ciclo de vida de estos. El corazón del ambiente virtual es vSphere y es vital mantenerlo actualizado.
vCenter Server Appliance (VCSA) de VMware es una máquina virtual preconfigurada basada en Linux, que está optimizada para ejecutar vCenter Server y los servicios asociados en Linux. Se usa para administrar y monitorear todo el ecosistema virtual VMware.
En este blog se describe el proceso para la actualización de VCSA de la v6.7 a v7.0 Update 3, además de sugerencias, trucos, posibles fallas comunes en el proceso, y las fechas importantes a considerar de VMware.
vSphere 7 marca el comienzo de una nueva era
vSphere 7 tiene muchas capacidades nuevas. Este enlace es el mejor para verlos todos enumerados y encontrar información técnica sobre cada uno:
https://blogs.vmware.com/vsphere/vsphere-7
También hay una publicación de blog que destaca las nuevas funciones de vSphere 7u3:
https://core.vmware.com/blog/vsphere-7-update-3-whats-new
vCenter 7.x solo está disponible como Virtual Appliance (VCSA):
https://blogs.vmware.com/vsphere/2017/08/farewell-vcenter-server-windows.html
vSphere 7u3c debería ser la versión mínima para actualizar, ya que resuelve las vulnerabilidades de Log4J:
https://blogs.vmware.com/vsphere/2022/01/anounce-availability-of-vsphere-7-update-3c.html
Problemas conocidos en 7u3
Hay algunos problemas conocidos con vSphere 7u3. Por ejemplo, si tiene máquinas virtuales con más de 8 TB de RAM, como es habitual con las bases de datos en memoria como SAP HANA, es posible que deba seguir la solución alternativa que se detalla aquí:
https://blogs.vmware.com/apps/2022/02/sap_hana_vsphere70u3c_and_cooper_lake_8s_support.html
Se incluye y actualiza una lista completa de problemas conocidos en las notas de la versión y en esta KB (Lista importante de artículos de la base de conocimiento identificados para la versión vSphere 7.0 U3c) https://kb.vmware.com/s/article/87327
Fechas importantes:
El ESXi v6.5 y 6.7 tienen su fin de soporte general (EOGS) el 15/Oct/22 (vCenter tiene las mismas fechas)
¿Qué significa Fin del soporte general?
https://www.vmware.com/support/policies.html#lifecyclepolicies
Documentación general sobre el proceso de actualización
Documentación de actualización de vSphere 7
https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.esxi.upgrade.doc/GUID-65B5B313-3DBB-4490-82D2-A225446F4C99.html
Este enlace centraliza la documentación de actualización y presenta la herramienta de evaluación de actualización de vSphere
https://www.vmware.com/products/vsphere/upgrade-center.html
Prácticas recomendadas de actualización de vSphere 7 KB
https://kb.vmware.com/s/article/78205
Información importante antes de actualizar a vSphere 7 KB
https://kb.vmware.com/s/article/78487
Publicación de blog de TAM sobre la actualización a vSphere 7
https://blogs.vmware.com/customer-experience-and-success/2022/03/your-4-step-vsphere-7-upgrade-guide-tips-from-a- vmware-tam.html
¿Por qué se recomienda la actualización?
Debido a la corrección de la vulnerabilidad log4j, se recomienda que todos los clientes actualicen al menos a 7u3c
https://blogs.vmware.com/vsphere/2022/01/anounce-availability-of-vsphere-7-update-3c. html
Tenga en cuenta que si su compilación 6.7 o 6.5 es más reciente (lanzada en una fecha posterior) que 7u3c, podría tener problemas con la actualización y tiene que usar una versión nueva de 7u3. Por ejemplo, en las tablas a continuación, vCenter 6.7u3q se lanzó en febrero de 2022, lo que significa que no debe intentar actualizar a 7u3c, lanzado en enero de 2022. Siempre intente actualizar a una versión reciente (por fecha) de vSphere 7, lo que le da la ventaja de las correcciones de errores.
Los números de compilación y las fechas de lanzamiento de vCenter se enumeran en https://kb.vmware.com/s/article/2143838
Los números de compilación y las fechas de lanzamiento de ESXi se enumeran en https://kb.vmware.com/s/article/2143832
vSphere 7u3 tuvo un comienzo difícil, ya que todas las versiones anteriores a 7u3c comenzaron a retirarse por problemas (“bugs”). Puede encontrar información histórica en estos dos enlaces:
https://blogs.vmware.com/vsphere/2021/11/important-information-on-esxi-7-update-3.html
https://blogs.vmware.com /vsphere/2022/01/anunciando-la-disponibilidad-de-vsphere-7-update-3c.html
Es muy importante leer las notas de lanzamiento de su versión:
Notas de la versión de vSphere ESXi 7 Update 3c
https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u3c-release-notes.html
Notas de la versión de vCenter Server 7 Update 3c
https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-vcenter-server-70u3c-release-notes.html
Este vínculo ya se mencionó en la primera sección, pero se reitera acá.
vSphere 7 Update 3c lista de problemas conocidos y soluciones alternativas https://kb.vmware.com/s/article/87327
Puntos destacados de las notas de la versión de ESXi 7u3
Cuando se anunció 7u3, se desalentó el arranque (“booteo”) desde el almacenamiento SD. Muchos clientes ya usaban tarjetas SD para el arranque y esto era un inconveniente, especialmente para una actualización menor. El código modificado se revirtió, pero se mantiene la recomendación de dispositivos de arranque de mayor calidad en el futuro.
https://blogs.vmware.com/vsphere/2021/09/esxi-7-boot-media-consideration-vmware-technical-guidance.html
https://kb.vmware.com/s/article/85685
- La partición “/locker” puede estar dañada cuando la partición se almacena en un dispositivo USB o SD
- Debido a la sensibilidad de I/O de los dispositivos USB y SD, la partición VMFS-L “/locker” en dichos dispositivos que almacena los VMware Tools y los archivos “core dumps” pueden dañarse.
Este problema se resuelve en esta versión, ya que de manera predeterminada, ESXi carga los paquetes “locker” en el disco RAM durante el arranque.
Aspectos destacados de las notas de la versión de vCenter Server 7u3
Se identificó un problema de controlador que detuvo la actualización. Tenga en cuenta la parte que hemos puesto en negrita en la siguiente declaración. Este documento asume actualizaciones de 6.7 principalmente, pero incluye esta información por si acaso.
Debido al reciente cambio de nombre en el controlador Intel i40en a i40enu y nuevamente a i40en, los hosts ESXi en algunos entornos posteriores a ESXi 7.0 Update 2a pueden tener ambas versiones del controlador, lo que genera varios problemas, todos resueltos en vSphere 7.0 Update 3c. Las versiones de ESXi afectadas son 7.0 Update 3a, 7.0 Update 3, 7.0 Update 2d y 7.0 Update 2c. VMware proporciona un script vSphere_upgrade_assessment.py que puede usar para identificar cualquier host ESXi que requiera corrección antes de iniciar una actualización de vCenter Server. Para descargar el script y obtener más información, consulte el artículo 87258 de la base de conocimientos de VMware y el video instructivo sobre la verificación previa de actualización de vCenter Server 7.0 Update 3c (7.0.3.00300). https://www.youtube.com/watch?v=xSA58Xzf8Wg
Cuando inicia la actualización de su sistema vCenter Server, una verificación previa ejecuta un análisis, para detectar si los hosts ESXi de las versiones afectadas por los problemas relacionados con el cambio de nombre del controlador de Intel existen en su inventario de vCenter Server. Si la verificación previa identifica dichos hosts ESXi, se ejecuta un análisis detallado para proporcionar una lista de todos los hosts afectados, especificando las ubicaciones de los archivos donde puede encontrar la lista y brinda orientación sobre cómo proceder.
Planificación de las actualizaciones para minimizar el riesgo desconocido
La historia enseña que ninguna planificación considerará todos los casos de uso. Por lo tanto, es mejor introducir estrategias destinadas a minimizar el riesgo.
Es importante desarrollar documentación específica de la empresa para el proceso de actualización. Esto permitirá que muchos colegas colaboren en las actualizaciones y las lecciones aprendidas para ser comunicadas. Las siguientes son consideraciones que deben tenerse en cuenta antes de decidir una fecha para las actualizaciones.
Copias de seguridad
El primer paso es tener copias de seguridad confiables. Confirme y pruebe que sus copias de seguridad funcionen correctamente antes de actualizar.
Tipos de copias de seguridad para comprobar y verificar antes de intentar actualizaciones:
- vCenter
- Conmutadores virtuales distribuidos
- Configuración de ESXi (especialmente importante ya que v7 usa un nuevo formato y borra la instalación anterior) https://kb.vmware.com/s/article/2042141
Compruebe también los medios de reinstalación para las versiones actuales de vSphere, así como los controladores/firmware de cualquier proveedor que serían necesarios para una situación de reversión.
Enfóquese primero en entornos con menos riesgo
Una forma de minimizar el riesgo es tener varios entornos independientes donde se puedan probar las actualizaciones en orden desde la menos impactante hasta la producción. Por ejemplo, comience con un verdadero entorno de prueba, que puede estar inactivo en cualquier momento y puede reconstruirse varias veces con diferentes controladores, firmware y configuraciones de hardware. La mayor preocupación es que puede que no tenga exactamente las mismas integraciones y hardware que la producción, pero la mayor ventaja es la práctica y la velocidad.
El siguiente debe ser cualquier entorno de desarrollo que no esté vinculado a las cargas de trabajo de producción. Con suerte, este entorno tiene algunas integraciones, como respaldo o monitoreo, y el hardware estaría en línea con la producción.
Un punto de conflicto podrían ser los entornos que están en modo vinculado. Las actualizaciones de vCenter requieren que todos los vCenters en modo vinculado se actualicen al mismo tiempo; sin embargo, estas actualizaciones deben planificarse con mucho cuidado.
Las actualizaciones del entorno de producción deben considerar el nivel de impacto, el hardware y la cantidad de integraciones. Un entorno VDI, por ejemplo, tiene más consideraciones que un entorno de servidor. Si es posible, desarrolle o simule estas integraciones en prueba o desarrollo.
Las actualizaciones de dVS conllevan cierto riesgo
Las actualizaciones de conmutadores virtuales distribuidos deben realizarse fuera del horario laboral, ya que pueden causar un «parpadeo» en la red. Lea y comprenda la siguiente KB
https://kb.vmware.com/s/article/52621
Use los servicios GSS y PSO para ayudarse antes de la actualización
Siempre abra un caso GSS proactivo antes de las actualizaciones. Presente su plan a GSS y pídales que lo verifiquen. Es posible que necesite 5 días hábiles o más, dependiendo de muchos factores, así que ábralo con tiempo. Por supuesto, puede hacer uso del servicio PSO Professional Services | VMware | LATAM.
Consideraciones de hardware
Se debe verificar la compatibilidad de hardware para todos los tipos de hardware implementados actualmente en el entorno utilizando la Guía de compatibilidad de VMware.
https://www.vmware.com/resources/compatibility/search.php
Se pueden aplicar varios filtros. A veces, el mismo modelo de servidor puede tener diferentes CPU familiares, por lo que esto también debe verificarse (la siguiente captura de pantalla no es completa, pero ha seleccionado la versión 7u3 ESXi y un fabricante para ver todos los servidores admitidos por ese proveedor)
Desarrolle y documente un plan de hardware, tanto para el software como para el firmware del hardware y las versiones de los controladores. Es necesario verificar el sitio web del proveedor de hardware para obtener la imagen ISO de instalación de ESXi recomendada, que debe incluir todos los controladores necesarios y el CD de actualización de firmware relacionado. Por lo general, incluyen notas de la versión o documentación de «receta» para asegurarse de que esté alineado. La página web de compatibilidad de hardware de VMware también se puede utilizar para verificar las combinaciones de firmware y controlador de dispositivo IO.
Es importante familiarizarse con el reemplazo de VUM (vSphere Upgrade Manager) llamado vSphere Lifecycle Management. Es similar, pero introduce nuevas características.
Estos dos enlaces son un gran comienzo:
https://core.vmware.com/resource/introducing-vsphere-lifecycle-management-vlcm
La mejor práctica es usar sus entornos de prueba para familiarizarse con la nueva interfaz.
Licencias
Una actualización de v6 a v7 requerirá la actualización de licencias. Documente las claves de licencia antiguas y su ubicación, y actualice las claves de licencia a medida que actualice los entornos. Necesitará licencias para todos los componentes actualizados, incluidos hosts individuales y vSAN.
Endurecimiento de la seguridad
Se debe realizar una revisión completa de los pasos de endurecimiento con esta actualización. Los pasos que se usaron para endurecer v6.7 serán diferentes en v7, aunque muchos serán similares.
Consulte siempre el enlace de la guía oficial de endurecimiento para encontrar la mejor recomendación:
https://www.vmware.com/security/hardening-guides.html
Siga el orden recomendado para todas las actualizaciones de componentes de VMware
Hay un orden de actualización específico cuando se instalan varios productos de VMware juntos. Familiarícese con esta KB y siga el orden en el documento de su plan de actualización.
https://kb.vmware.com/s/article/78221
Comprobación de las dependencias de integración de vCenter
vSphere se integra con muchas soluciones. La mayoría de las integraciones se realizan a nivel de vCenter. Estos incluyen soluciones de VMware y de terceros.
Desarrolle una lista de todos los entornos y qué integraciones de software existen. Los más comunes incluyen respaldos, monitoreo, automatización, hardware y complementos de almacenamiento. Puede usar esta tabla como ejemplo de la documentación que debe crear:
Utilice la matriz de interoperabilidad de productos para verificar las versiones aplicables
https://interopmatrix.vmware.com/Interoperabilidad
Por ejemplo, se requiere que SRM tenga la versión 8.5 para ser compatible con vSphere 7u3:
Desarrolle esta lista antes de comenzar las actualizaciones. Aportará claridad sobre qué sistemas comparten integraciones (por ejemplo, la misma plataforma de copia de seguridad puede dar servicio tanto a entornos de desarrollo como de producción) y evitará muchos dolores de cabeza evitables.
Espacio libre de VCSA
Obtendrá una opción para migrar los datos más esenciales o también para incluir tareas, eventos y métricas de rendimiento. Puede comparar el tamaño de los datos con el espacio libre disponible en el vCenter de origen. Cuando los datos son más grandes que el espacio libre disponible, se le pedirá una ubicación diferente a /. Por lo general, encontrará que la partición VUM tiene mucho espacio libre (usando el comando df -h ) y puede proporcionarlo, consulte esta publicación de blog de Luciano Patrao o consulte con GSS.
Herramienta de diagnóstico de vSphere (“vSphere Diagnostic Tool”)
Una herramienta que VMware GSS ha puesto a disposición del público en forma de lanzamiento es capaz de detectar muchos problemas en los entornos de vCenter antes de que se conviertan en un problema a mitad de la actualización. Es una buena idea ejecutar esto y compartir el resultado en su caso GSS proactivo, ya que puede mostrar algunas tareas que deben realizarse antes de intentar la actualización.
https://flings.vmware.com/vsphere-diagnostic-herramienta
Otros recursos para prepararse
Revise las publicaciones del blog de Lucho DeLorenzi , que son muy útiles, especialmente cuando desea ensuciarse las manos y verificar usted mismo el estado de sus vCenters. Esto debería estar cubierto durante su caso proactivo con VMware GSS, pero por si acaso 🙂
https://luchodelorenzi.com/2021/04/05/como-llego-a-vsphere-7-0-sin-morir-en-el-proceso/
El video está en español, cortesía del VMUG de Argentina
https://luchodelorenzi.com/2020/04/10/pre-upgrade-considerations-in-multi-vcenter-environments/
Ejecución de la actualización
Esta sección es un buen comienzo, pero tendrá que adaptarse y expandirse a su entorno y condiciones. Coloque la VM de VCSA en un host conocido y detenga el movimiento automático de las VM, poniendo DRS en modo manual. También puede clonar la VM de VCSA como una copia de seguridad adicional o crear un snapshot, pero tenga en cuenta que los vCenters en “linked mode” necesitan una snapshot en frío (tomarlo cuando cada VCSA apagado) de todos los vCenters vinculados, y esto es algo que debe hacer en coordinación con GSS.
Lista de verificación de preparación para el día de actualización
- Terminar el plan de documentación de actualización
- Reúna la dirección IP temporal para vCenter(s)
- Reúna los ISO (y/o los paquetes de actualización) de software necesarios. Verifique y asegúrese de que el valor MD5SUM de los paquetes descargados coincidan con el valor MD5SUM especificado en el sitio web de descarga.
- Pruebe las credenciales de acceso remoto del host ESXi
- Establecer una ventana de mantenimiento más larga de lo necesario
- Tenga a mano un número de caso GSS proactivo
Orden de ejecución durante la actualización
Una orden de ejecución real debe estar en su plan de documentación de actualización.
El siguiente es un ejemplo (que no pretende ser exhaustivo):
- Hacer copia de seguridad del entorno (“backups”)
- Actualizar el servidor vCenter (VCSA)
- Instalar o actualizar complementos de vCenter (“plugins”)
- Actualizar los hosts ESXi
- Actualice los conmutadores distribuidos de vSphere (“vDS”)
- Actualice las herramientas de VMware (“VMware Tools”)
- Actualice el hardware virtual de VMware (“VM hardware version”)
- Actualice el formato en disco de vSAN a la compatibilidad con 7.0
- Actualice la infraestructura de Cisco UCS (si los hosts usados son Cisco UCS)
- Actualice los servidores de la serie C de Cisco UCS con HUU
- Actualice la infraestructura de la matriz de almacenamiento (“storage”)
dVS v7: nuevas funcionalidades
vSphere v7 incluye nuevas funcionalidades para el conmutador virtual distribuido, que se pueden revisar aquí:
Consideraciones posteriores a la actualización
Verifique que todas las integraciones, usuarios, monitoreo y automatizaciones estén funcionando, luego puede realizar pruebas. A medida que resuelve cualquier problema en cada entorno, documente las correcciones como lecciones aprendidas para el próximo entorno.
Si creó “snapshots”, no las guarde por mucho tiempo. Los “snapshots” pueden estresar el sistema de almacenamiento y solo son útiles durante unas pocas horas. Si es necesario, 2 días deberían ser una ventana de tiempo más que suficiente para haber realizado una buena copia de seguridad. ¡Bórrelas!
Conclusiones
Las actualizaciones de los productos VMware aseguran un apropiado funcionamiento y soporte durante el ciclo de vida de estos. Información al respecto en: https://www.vmware.com/latam/support/policies/lifecycle.html
Si después de revisar toda información detallada arriba, desea acompañamiento durante el proceso de actualización, o que todo el proceso sea hecho por profesionales por usted, contáctenos: https://www.vmware.com/latam/professional-services.html https://www.v2s.us/contactos/
¡Disfrute de vCenter 7!
Escrito por: Walter Solano Sanchez – V2S Senior Consultant
Referencias
Adaptado de https://github.com/arielsanchezmora/vSphere-67-Upgrade-to-7u3
La regla de backup 3-2-1 de Veeam
https://portfolio.v2s.us/wp-content/uploads/2022/05/La-regla-de-backup-3-2-1-de-Veeam.mp4
La regla 3-2-1 es muy general y funciona para todo tipo de datos (individuales y corporativos) en entornos físicos y virtuales.
Al realizar la regla en copias de backup de entornos VMware o Hyper-V con Veeam, se convierte en la “regla de backup 3-2-1-0”, en la que 0 significa “0 errores” durante la verificación automática de la recuperabilidad de cada backup con SureBackup de Veeam.
Veeam Backup & Replication puede ayudarlo a cumplir con todos los requisitos de la regla de backup 3-2-1:
- Tener al menos tres copias de sus datos: configure trabajos de backup para crear varias copias de cada una de sus VM de VMware o Hyper-V.
- Almacenar las copias en dos medios diferentes: Veeam es un almacenamiento agnóstico, lo que significa que es compatible con cintas, discos, la nube y más. Puede almacenar sus copias de backup en cualquiera de los medios enumerados.
- Tener una copia de backup en un medio externo: configure trabajos de copias de backup para transferirlas más rápido a un medio externo con la Aceleración WAN integrada o utilice Veeam Cloud Connect para almacenar copias de backup en un medio externo en una infraestructura de proveedor de servicios.
La Regla 3-2-1 nos ayudará a tener más conciencia sobre la importancia que tienen los respaldos de los ambientes productivos ante un desastre.
Los objetivos de recuperación de ambientes productivos ante un desastre
El tiempo de inactividad no es una opción para las organizaciones modernas que deben satisfacer las necesidades y expectativas de sus clientes. Se pueden producir varios incidentes que tengan un impacto en los ingresos de su negocio o incluso en su existencia, ya sea un ataque de ransomware, un corte de energía, una inundación o simplemente errores humanos, estos eventos son impredecibles y lo mejor que puede hacer es estar preparado.
Estar preparado significa que debe tener un plan sólido de Continuidad Comercial y Recuperación ante Desastres (BCDR, por sus siglas en inglés). Uno que haya sido probado y pueda ponerse en marcha sin problemas.
Dos de los parámetros importantes que definen un plan BCDR son el Objetivo del Punto de Recuperación (RPO, por sus siglas en inglés) y el Objetivo del Tiempo de Recuperación (RTO, por sus siglas en inglés). Para quienes no están familiarizados con estos términos, permítanme darles una breve descripción:
- RPO limita la distancia de retroceso en el tiempo y define la cantidad máxima permitida de datos perdidos desde la ocurrencia de una falla, hasta la última de backup válida.
- RTO está relacionado con el tiempo de inactividad y representa cuánto se tarda la restauración desde el incidente hasta que las operaciones normales estén disponibles para los usuarios.
Si bien RPO y RTO pueden parecer similares, sirven para diferentes propósitos y en un mundo ideal, sus valores serían tan cercanos a cero como sea posible. Sin embargo, de vuelta en nuestro mundo, el costo cero para RPO y RTO sería extremadamente costoso y podría no valer la pena el esfuerzo.
Cómo definir los valores de RTO y RPO para sus aplicaciones
A razón de que las empresas son diferentes y tienen distintas necesidades, no existe una solución única para un plan de continuidad del negocio y sus métricas, por lo tanto, tienen diferentes requisitos para sus objetivos de recuperación. Sin embargo, una práctica común es dividir aplicaciones y servicios en diferentes niveles, así como establecer los Valores de Tiempo de Recuperación y Objetivo (RTPO, por sus siglas en inglés) de acuerdo con los Acuerdos de Niveles de Servicio (SLA, por sus siglas en inglés), con los que se compromete la organización.
La clasificación de protección de datos es importante para determinar cómo almacenar, acceder, proteger, recuperar y actualizar datos e información de manera más eficiente en función de sus criterios específicos. Es de suma importancia analizar sus aplicaciones y determinar cuáles de ellas están impulsando su negocio, generando ingresos y siendo imprescindibles para mantenerse operativo. Este proceso, que es esencial para un buen plan de continuidad comercial, se denomina Análisis de Impacto del Negocio (BIA, por sus siglas en inglés), que establece protocolos y acciones para enfrentar un desastre. Por ejemplo, puede usar un modelo de tres niveles para diseñar su plan de continuidad del negocio:
- Nivel 1: Aplicaciones esenciales que requieren un RTPO de menos de 15 minutos.
- Nivel 2: Aplicaciones esenciales para un negocio que requieren RTO de 2 horas y RPO de 4 horas.
- Nivel 3: Aplicaciones no esenciales que requieren RTO de 4 horas y RPO de 24 horas.
Es importante tener en cuenta que las aplicaciones esenciales, para un negocio y las no esenciales, varían de una industria a otra, y cada organización define estos niveles en función de sus operaciones y requisitos.
Autor:
Jesús Daniel Montes Ramirez
COMPARTE ESTE POST
Share on facebook
Share on twitter
Share on linkedin
Share on whatsapp
Share on print
Share on email
Fundada en 2006, V2S Corporation es una multinacional de Servicios de Infraestructura y Aplicaciones para todos los sectores e industrias.
Somos expertos en soluciones innovadoras de Virtualización como respuesta a los retos actuales de Transformación Digital.
Nuestras soluciones personalizadas y el conocimiento de los distintos sectores son nuestros principales diferenciadores. Llevamos años auditando, diseñando, implementando y gestionando las soluciones de virtualización más avanzadas. Nuestros servicios se enmarcan dentro del profesionalismo, la precisión, la innovación y la calidad.
V2S Corporation opera globalmente desarrollando proyectos en distintos países. Tenemos oficinas y personal en Europa, África y América Latina. Aunque nuestras operaciones están muy extendidas, nuestro enfoque es operar como una empresa multinacional global centrada en la calidad del servicio. La misma metodología y enfoque están presentes allí donde ofrecemos nuestros servicios adaptándonos al mismo tiempo, a los retos locales.