Mostrando entradas con la etiqueta VMware vSphere. Mostrar todas las entradas
Mostrando entradas con la etiqueta VMware vSphere. Mostrar todas las entradas

18 octubre 2016

vSphere 6.5 announced at VMworld 2016 Barcelona

vSphere 6.5 was announced at VMworld 2016 Barcelona.
As you may know, VCSA is the recommended deploy option since vSphere 6 was released in Feb`2015 and most of the new improvements are realted with that, for example, now we have native high availability for VCSA, the VUM (VMware Update Manager) is now integrated (remember that in vSphere 6.0 we need to install it only on Windows) and the new native backup and restore options which cover most of the complaints with the VCSA.


  • ·      VMware vCenter Server® Appliance - will deliver a simplified building block for vSphere environments offering an easy to deploy and manage approach that reduces operational complexity by embedding key functionality into a single virtual appliance. The appliance will offer customers simplified patching, upgrading, backup and recovery, high availability and more, including a 2x increase in both scale and performance of their vCenter Server environments.
  • ·      REST APIs - will improve both the IT and developer experience by enabling greater control and automation of virtual infrastructure for modern applications via new REST-based APIs.
  • ·      VMware vSphere Client - based on HTML5, the new vSphere Client will simplify the administrative experience via a modern, native tool that meets the performance and usability needs and expectations of users for day-to-day operations.
  • ·      VM Encryption - new virtual machine-level encryption will protect against unauthorized data access safeguarding data at rest as well as virtual machines that are moved with VMware vMotion®.
  • ·      Secure Boot - new feature will prevent the tampering of images as well as the loading of unauthorized components into vSphere environments.
  • ·      VMware vSphere Integrated Containers™ - will allow IT operations teams to provide a Docker-compatible interface to their app teams enabling vSphere customers to transform their businesses with containers without re-architecting their existing infrastructure.


Two great features for me right now is to have the option to backup and restore the VCSA removin the dependency with third party backup solutions in one hand, and to have the option  to secure and encriptyon the VMs in other hand, so security is now done with VCSA 6.5




In the next post i´ll cover one by one the new features, meanwhile you can check the official landing page: http://blogs.vmware.com/vsphere/2016/10/introducing-vsphere-6-5.html

11 septiembre 2016

vSphere 6 upgrade: repoint replicated embedded SSO or PSC to external PSC

One of the keys of the new vSphere 6 topology is decided which scenario will fits better following the best practices. The main best practice is deploy external PSC as it will help us to get high availability SLA and an easier upgrade path for the future. keep in mind that VCSA is the recommended option to deploy vCenter right now.

First of all, review on this image the upgrade path from the two different platforms: Windows Server and VCSA (vCenter Server Appliance):

















Go ahead with a specific and common scenario: SSO embedded replicated between at least 2 vCenters.



First step is to deploy an external SSO replicating with the embedded SSO, second step is repoint vCenters to the external SSO and third uninstall the embedded SSO:


The quid here is the process to "repoint" the SSO, follow this KB and you´ll see it´s a piece of cake:


If you have PSC embedded instead the SSO embedded just follow this kb:


Once you have the new external SSO working, just upgrade it to PSC:


And last but not least, upgrade the vCenter 5.x to vCenter 6.x



You can use the same steps to upgrade a single vCenter install with embedded (or not) SSO or PSC.

Finally, remember that VMware recomeends:
  • Deploy VCSA
  • Deploy external(s) PSC
  • Select a VMware "recommended" topology




04 septiembre 2016

MicrosegmentaciĂłn con Firewall Distribuido de NSX (DFW)

Revisemos primero los tipos de FW que disponemos:

-Fisicos: aunque aun son necesarios, los cortafuego perimetrales tienen limitaciones sobre el ancho de banda que pueden gestionar asi como la carga de analisis que obliga a una escalabilidad horizontal compleja y que aumenta la complejidad del entorno.

-Virtuales, mismo servicio que los fisicos pero en formato virtual, son un buen complemento para los FW fisicos aunque estan limitados a una mdia de 1 y 4 Gb de ancho de banda.

-Distribuidos: son el complemento perfecto para los fw fisicos en un entorno de vSphere. EL FW de NSX esta basado en el rendimiento del kernel del hypervisor (ESXi), permiten una gran escalabilidad horizontal muy agil y que no implica aumentar la complejidad del entorno y que permite un ancho de banda de hasta 20Gbps por host.



















Gracias al nuevo paradigma que presentan los servicios distribuidos de NSX, como en este caso el de FW,  es posible plantear otros escenarios a donde las capas de los servicios fisicos tradicionales no estaban llegando, en este caso, el esquema de firewall perimetral se amplia a un esquema de una relacion 1:1 entre VM y FW como vemos en al siguiente imagen:


De la idea anterior nace el concepto de "microsegmentaciĂłn": el trafico se inspecciona ahora en las tarjetas de las maquinas virtuales a nivel de capa 2, 3 y 4 gracias a NSX.
Ademas permite integraciĂłn con soluciones de terceros que aumentan la capacidad de analisis de las aplicaciones como de capa 7.
Por ultimo es importante destacar que si la VM se mueve de host hypervisor (ESXi), las reglas de esta VM se van con ella, y no es necesario ningun tipo de reconfiguracion con lo que es 100% compatible con las tecnicas de asignacion dinamica de recursos (DRS) y de caracteristicas como HA de VMware para dotar de alta disponibilidad a las maquinas virtuales. 




















La microsegmentacion nos permite aislar y segmentar las aplicaciones de diferentes formas como podemos ver en la siguiente imagen:


28 agosto 2016

Rendimiento del Firewall Distribuido (DFW) de NSX

En los siguientes post, desmontaremos algunos de los mitos que existen sobre el rendimiento y la visibilidad de operaciones que existen relacionadas con NSX, en este caso nos centraremos el el rendimiento del cortafuegos implementado por NSX.



Una buena metrica para analizar el rendimiento del DFW de NSX; es medir las conexiones por segundo que puede alcazar un firewall con un numero determinado de reglas.
En el siguiente grafico vemos como incluso con 100 reglas de firewall por host se alcanzan sin problemas las 80.000 conexiones por segundo.



























En la siguiente gráfica podemos observar como apenas hay perdida de rendimiento incluso cuando se transmiten 20Gbps a través de un solo host (con dos enlaces de 10 Gbps)


Es importante tener en cuenta que con el DFW (Firewall Distribuido de NSX) la carga que debe soportar y gestionar cada FW es el de las VMs que residen en ese host o del trafico que se envia y/o recibe en un solo host; a diferencia de los FW fisicos tradicionales que tienen que soportar el trafico de todo el entorno tanto fisico como virtual ya que son un punto Ăşnico de filtrado de trafico. Esto ademas obliga a que el trafico circule por toda la ed hasta llegar la FW fisico, en cambio con el DFW de NSX, se llega al extremo de que si el trafico es entre VMs ubicadas en el mismo no host no tengan ni que salir del host para comunicarse entre ellas.

Ademas, la posibilidad de combinar las vRealize Automation (vRA) con NSX, nos permite implementar las aplicaciones y los servicios de forma muy ágil y flexible:
-implementaciones de aplicaciones multinivel en redes aisladas.
-implementaciones de VMs en redes planas.
-implementaciones de reglas para aplicaciones que se apliquen en el momento de su activaciĂłn.
-implementar servicios combinados de FW y LB o VPNs


19 agosto 2016

Componentes de VMware NSX

Los componentes de la solución de virtualización de red NSX de VMware se dividen en tres areas o planos: Plano de Gestión, Plano de Control y Plano de Datos. Ademas de estos tres planos basicos, tambien se incluyen los componentes para integracion con la plataforma de gestion cloud o CMP a través de vRealize Suite.

Ahora veamos cuales son los componentes y/o funciones de cada plano en la siguiente tabla:

Plano de Datos (Data Plane)
Los modulos de cortafuegos distribuido (DFW), enrutador lĂłgico  NSX virtual (DR) y puertos VXLAN son implementados por NSX Manager en el VMkernel de cada host (hypervisor ESXi).
Los enrutadores lĂłgicos y distribuidos son los que permiten trafico este-oeste.
Las puertas de enlace o gateways de NSX Edge se implementan como una maquina virtual se encargan de permitir el trafico norte-sur (dispone de servicios de cortafuegos, balanceo y servicios basados en VPN)

Plano de Control (Control Plane)
En este plano nos encontramos con los enrutadores lĂłgicos de NSX (NLR), el NSX Controller y el gestos de usuarios global (UWA).

Plano de GestiĂłn (Management Plane)
En este plano tenemos la interfaz de gestion de usuario unificada para controlar y gestionar vSphere y NSX desde el Web Client.

Modelo de Consumo (CMP)
En el CMP tenemos el portral de autoservicio y automatizacion de cloud y NSX (basado principalmente en vRealize Automation (vRA))





13 septiembre 2015

VMworld San Francisco 2015: resumen

En este post podrĂ©is leer un resumen de las novedades y tendencias presentadas en el pasado VMworld 2015 SF (USA) cortesĂ­a de Jose M. Maldonado (Global Solutions Consultant en VMware.) @maldonjo


DevOps y contenedores

VMware Integrated Containers - Permite la ejecución de aplicaciones en contenedores directamente sobre la infraestructura vSphere o en vCloud Air, haciendo uso de las mismas capacidades y procesos actualmente existentes. Actualmente en fase beta podrá comenzar a probarse a finales de año de cara a usar el propio vSphere como un host para Docker. Permite que los desarrolladores utilicen sus herramientas Docker preferidas e IT soporte los servicios con la misma disponibilidad y flexibilidad como hasta ahora, pudiendo gestionarlos directamente desde vCenter.
  • Niveles de servicio garantizados, permite que los contenedores se comporten como máquinas virtuales: DRS, vMotion, HA/DR … minimizando el tiempo de indisponibilidad planificado.
  • Utiliza las capacidades de Instant Clone para levantar nuevas VMs para ejecutar contenedores en base a las necesidades o el orquestado del servicio
  • Integrable con el ecosistema de soluciones: Cloud Foundry, CoreOS, Tectonic, Docker, Kuebernetes, Mesosphere DC Operating System, …
  • Garantiza la seguridad, aislamiento y autenticidad de los contenedores arrancando cada uno en una VM de forma eficiente gracias al vSphere Instant Clone
  • Si se requiere almacenamiento y persistencia de datos, se podrán desplegar volĂşmenes de datos asociados a contenedores sobre plataforma vSphere.
  • ComunicaciĂłn granular gracias a NSX, pudiendo aplicar configuraciones en base a polĂ­ticas a cada uno de los contenedores por separado



VMware Photon Platform - Es una plataforma optimizada para la ejecuciĂłn de contenedores con gestiĂłn basada en APIs, compuesta por dos elementos:

  • Máquinas Photon: Son los hosts de computaciĂłn, sencillos, horizontalmente escalables y fácilmente reemplazables, con un "microvisor" basado en ESXi y un sistema operativo Linux optimizado para la ejecuciĂłn de contenedores
  • Controlador Photon: Controlador de hosts y orquestador de cargas de trabajo con un plano de gestiĂłn distribuido y multi-tenant
CONTINUAR... 

27 abril 2015

vRealize Operations Manager 6 - Part V - Create Custom Groups with vSphere Tags


One of the best vROps (old vCOps) features is the option to create custom groups where you can define the criteria membership and apply a policy rule to them.

There is a lot of environments where the Virtual Machines are not properly configured and defined, with the vSphere Folders or inventory VM names, no naming convention, etc.... 
Is here where the "vSphere Tags" win the game! You can easily tag your VMs!  ..use PowerCLI!!!! (next post incoming)

Imagine that you need to create a policy rule and a Custom Group but your VMs in vSphere are not organized...  Are you thinking in add one-by-one to a Custom Group? and what if tomorrow you add new VMs? ...manually adding Vms is not a good idea, so try to tag your VMs when you create it on the vSphere environment and keep it updated with your CMDB database.

But, how to tag your environment properly?  First of all, you "must" have clear the tags you want to add and how to categorize it.  Just an example, filter you DDBB Vms  (SQL, Oracle, MongoDB, etc) or filter by App Vms, or Bckp environment, or AV environment... and so on.....

Once you have your VMs tagged, you can create a custom group as shown below:






See previous Part I    -vRealize Operations Manager 6 - Part I - OVA deployment
See previous Part II   - vRealize Operations Manager 6 - Part II - Express Installation
See previous Part III  - vRealize Operations Manager 6 - Part III - Manage Solution
See previous Part IV  - vRealize Operations Manager 6 - Part IV -  How import LDAP users

Related with:  VMware vSphere: how to create tags - Part I


20 abril 2015

VMware vSphere: how to create tags - Part II with PowerCLI

On the Part I post we learn how to add a Tag and a Category trough the GUI interface with vSphere Web Client, now, let´s take a look about how to do it with PowerCLI.


Remember that Tags are a new feature available from vSphere 5.1 and the cmdlets are available from PowerCLI 5.5, so, we need at least a vCenter on vSphere 5.1 and the PowerCLI 5.5 installed but much better use las version PowerCLI 6 (not all cmdlets are present in PowerCLI 5.5 initial release)

Use this to verify the version you have installed: 
PowerCLI C:\> Get-VIToolkitVersion


Now with the New-Tag we can review the Tags configured, and with "New-TagCategory" create a Category and after with "New-Tag" the Tag



Now, we are ready to assign Tags to objects, in this case to Virtual Machine:


It´s time to verify it trough Web Client:





Something i didn´t mention jet, is that you can assign multiple Tags to an objet in vSphere , in our case to a Virtual Machine. It means that you can for example tag a VM with the "DDBB_tag" because it´s a SQL DDBB, and Tag it with "Cluster_tag" because it´s a Microsoft Cluster, or with another tag like "Test_tag" because it´s a DDBB SQL Cluster from the Lab Environment.

Why multiple Tags? For vROps it will be useful to create custom groups using different Tags criteria and fix different policies if its a VM from DDBB servers, or if its a VM from Lan Environment..... one VM could be placed in different Custom Groups at the same time :-)


First Part of this post: VMware vSphere: how to create tags - Part I