Blog

9 septiembre, 2021

Diseño de Arquitectura TI y Examen Advance Desing de VMware

Hace poco, me anime a dar nuevamente el examen de Diseño Avanzado de VMware, VCAP. Fue un examen complejo, tiene 60 preguntas donde tienes que dominar temas como:

  • ESXi
  • vCenter
  • vSAN
  • NSX
  • SRM
  • vRealize
  • HA
  • DRS
  • SDRS
  • vSwitch
  • vLAN y VXLAN
  • vMotion

Entre otras cosas, es un gran contenido, pero además de eso, la complejidad (bajo mi punto de vista) es entender bien las suposiciones que te están planteando y saber bien que caminos sobre el mejor diseño para responder las necesidades planteadas en cada pregunta.

Los puntos descritos anteriores creo que los vas sorteando con sus respectivos cursos, pero por sobre todo con experiencia, pero hay otro que no y es lo que quiere tratar de dejar una pequeña ayuda en este artículo.

Antes de dar este examen, tuve la suerte de participar de curso de Desing vSphere 7 (sumamente recomendado si quieres dar el examen). En él, se tocan los puntos de como abordar los proyectos con los clientes y una serie de conceptos que seguramente manejan, pero a veces no tenemos la conciencia que los estamos utilizando. Les voy a hablar un poco del modelo conceptual de los proyectos.

Modelo Conceptual:

Lo primero que debemos tener claro cuando tomamos un proyecto de un cliente es encontrar 4 puntos fundamentales para llevar el diseño en un correcto camino:

Requisitos, Restricciones, Supuestos y Riesgos.

Los requisitos comerciales los proporcionan las partes interesadas clave (en el caso nuestro el cliente) y el objetivo de cada solución es lograr cumplir (ojalá) con cada uno de estos requisitos.

Las restricciones son condiciones que proporcionan límites al diseño. Estos a menudo se confunden con los requisitos, pero recuerden que un requisito debe permitir al arquitecto evaluar múltiples opciones y tomar una decisión de diseño, mientras que una restricción limita las respuestas y elimina la capacidad de decisión del arquitecto.

Los supuestos enumeran las condiciones que se cree que son verdaderas, pero no están confirmadas: En el momento de la implementación, todas las suposiciones deben validarse. Por ejemplo, el cliente solicita un crecimiento en cantidad de VMs en la plataforma y nos indica que se deben respaldar en su actual plataforma de backup. Podríamos asumir que el cliente tiene la capacidad de respaldo para las nuevas VMs, pero claramente debemos validar.

Los riesgos son factores que pueden afectar negativamente al diseño (no podría ser de otra forma). Todos los riesgos deben mitigarse, en lo posible.

Requisitos Generales

Describe lo que se debe lograr en el proyecto; describe cómo se verá la solución.

Ejemplo: la organización debe cumplir con las reglas de backup 3-2-1-0

Ejemplo: la arquitectura debe contar con un site de contingencia y su plan de recuperación.

Ahora, algo muy importante y si quieres hacer el examen, debes saber muy bien las diferencias entre los requisitos funcionales y los no funcionales.

 

 

 

 

 

 

Requerimientos funcionales

Un requisito especifica una función que debe realizar un sistema o componente. Estos pueden incluir:

  • Reglas del negocio
  • Autenticación
  • Seguimiento de auditoría
  • Requisitos de certificación
  • Los requisitos de información
  • Información histórica
  • Requisitos legales o reglamentarios

Otros ejemplos incluyen los siguientes requisitos:

  • La solución debe admitir 200 máquinas virtuales que se ejecutan simultáneamente.
  • La solución debe escalar en un 20 por ciento durante los próximos tres años.

Requerimientos no funcionales

Un requisito no funcional es una declaración de cómo debe comportarse un sistema. Estos pueden incluir:

  • Rendimiento: tiempo de respuesta, rendimiento, utilización, volumétrico estático
  • Escalabilidad
  • Capacidad
  • Disponibilidad
  • Recuperabilidad
  • Seguridad
  • Manejabilidad
  • Interoperabilidad

Restricciones

Cualquier cosa que limite la elección de diseño realizada por el arquitecto. Si no hay varias opciones disponibles para tomar una decisión de diseño, entonces es una limitación.

Ejemplo: debido a una compra anterior, ya se ha seleccionado el hardware de host.

Supuestos

Los supuestos son componentes de diseño que se supone que son válidos sin pruebas. Las suposiciones documentadas deben validarse durante el proceso de diseño. Esto significa que en el momento en que se implementa el diseño, no debe haber suposiciones.

Ejemplo: la organización tiene suficiente ancho de banda de red entre sitios para facilitar la replicación.

Riesgos

Un riesgo es cualquier cosa que pueda impedir la consecución de los objetivos del proyecto. Todos los riesgos deben mitigarse con procedimientos operativos estándar claros.

Ejemplo: La replicación entre Datacenter se realiza a través de un solo enlace.

Ejemplo: La arquitectura esta implementada con NSX pero el personal de la compañía no tiene suficiente conocimiento para trabajar con el producto.

El diseño de las plataformas es una de las cosas que más me apasiona en el mundo del TI y tener esa felicidad cuando lo diseñado en el papel está funcionando y con un cliente feliz, mejor aún.

 

 

 

 

 

 

Ahora, si quieres dar ese examen, ten presente muy bien estos conceptos, se repiten bastante en las preguntas y bajo mi punto de vista, hay un margen grande para los “puntos de vistas”. Cuando enfrentas las preguntas, uno piensa, yo lo haría de esta manera, el problema es si el equipo que diseño la pregunta esta pensando lo mismo que tú.

Es un examen complejo sin dudas, pero muy desafiante y entretenido.

Información obtenida del manual de lectura de vSphere Desing 7

RECUERDA 5 al 7 de octubre VMWORLD 2021! ONLINE y GRATIS!

 

 

José Luis Fernández

VCP-DCV / VCP-DM / VCAP/ vSAN Specialist / vExpert

 

Uncategorized

Deje un Comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *