X

News, tips, partners, and perspectives for the Oracle Solaris operating system

Agrupación en clústeres de invitados de Solaris que se ejecutan en VMware con el software Sun Cluster 3.2

Guest Author

La virtualización en el mundo de hoy en día está en el punto de mira. En la era de máquinas de gran potencia, no se recomienda dedicar una pieza entera de costoso hardware a una única causa. Desde la ejecución de varias aplicaciones y varios sistemas operativos (OS) hasta varios dominios hardware, el objetivo consiste en simplificar al máximo su uso. Sin embargo, para sacar partido de los aspectos positivos de la virtualización, las aplicaciones deben ser lo suficientemente compatibles. Gran parte del software actual se ejecuta en plataformas virtuales como si la virtualización fuera transparente, lo que en realidad es el verdadero objetivo.

Como objetivo de este experimento, se eligió VMware como tecnología de virtualización, debido, en gran parte, a que se ha estado presente desde hace ya algún tiempo. La compatibilidad del sistema operativo Solaris(TM) 10 (versiones de 32 y 64 bits) como sistema operativo invitado, ya está presente en varias versiones de VMware. VMware ESX Server 3.0.1 (http://www.vmware.com/products/vi/esx/) con las características que ofrece, fue la plataforma elegida. Podrá encontrar documentación para el servidor VMware ESX en http://www.vmware.com/support/pubs/vi_pubs.html. Me gustaría comentar que he probado VMware Workstation y VMware Server, pero, en determinadas áreas, como, por ejemplo, los dispositivos compartidos y de red en una configuración agrupada en clústeres con software Sun Cluster 3.2, surgían problemas en aspectos tales como las interconexiones privadas y el aislamiento de dispositivos.

El objetivo era ejecutar el software Sun Cluster 3.2 en los principales sistemas operativos invitados Solaris 10 y, por tanto, agrupar máquinas virtuales VMware que ejecuten el sistema operativo Solaris. La suposición inicial era que, dado que el sistema operativo Solaris se ejecuta en VMware sin ningún tipo de problema, el software Sun Cluster debía funcionar del mismo modo. Resulta lógico mencionar que se tratan de pasos iniciales en esta dirección y el equipo de Sun Cluster está investigando de forma continua diversas técnicas de virtualización y compatibilidad de Sun Cluster con estas funciones. La configuración mencionada en este apartado se realizó en la versión de 32 bits de Solaris (ya que era el hardware disponible en el momento de esta configuración), pero debo decir que estoy convencido de que no habrá ninguna diferencia en un entorno de 64 bits.

A continuación, se indican diversos aspectos de la configuración. Los nodos e invitados que se mencionan aquí hacen referencia a los invitados virtuales Solaris en VMware ESX Server, que se agruparán en clústeres utilizando el software Sun Cluster 3.2.

P.D.: las imágenes se han mostrado en miniaturas para que no ocupen demasiado espacio en el blog. Haga clic en las imágenes para aumentar su tamaño.

I ) Nº de nodos de clúster
El software Sun Cluster dictaría el número máximo de nodos que pueden admitirse. Que aparezca VMware en la imagen no afecta a este aspecto. La configuración se ha probado con clústeres de 2 y 3 nodos. Para fines ilustrativos, contamos con un máximo de 3 hosts físicos (máquinas SunFire V20z de doble CPU y con 4 GB de RAM), con cada uno de los nodos agrupados en clústeres en un host físico distinto. Sin embargo, podría fácilmente extrapolarse a los miembros del clúster de la misma máquina física o de una combinación.

II) Almacenamiento
VMware ESX Server ofrece diversas formas para agregar dispositivos de almacenamiento SCSI virtuales en los invitados Solaris que se ejecutan en él. Los dispositivos virtuales VMware pueden encontrarse en:

  • Almacenamiento SCSI de conexión directa


  • Matrices SAN de canal de fibra


  • Matrices iSCSI SAN


  • NAS


En todos los casos en los que VMware ESX Server extrae alguno de los dispositivos de almacenamiento subyacentes, de modo que el invitado sólo visualiza un disco SCSI, no existe un control directo de los dispositivos desde el invitado. El problema es que cuando se agrupa en clústeres, las reservas SCSI parecen que no funcionan tal y como se esperaba en todos los casos. Los algoritmos de aislamiento de Sun Cluster para dispositivos compartidos requieren reservas SCSI. De modo que si las reservas SCSI no funcionan, esto no beneficiará a nuestro objetivo. Sin embargo, se puede utilizar dichos dispositivos cuando el objetivo no es compartirlos entre nodos de clúster, es decir, deberían ser dispositivos locales.

No obstante, VMware ESX cuenta con una función denominada Asignación de dispositivos sin formato (RDM) que permite que los sistemas operativos invitados tengan acceso directo a los dispositivos, evitando la capa de VMware. Podrá encontrar información adicional sobre RDM en la documentación de VMware. Los documentos que se indican a continuación pueden servir de punto de partida:

http://www.vmware.com/pdf/vi3_301_201_intro_vi.pdf

http://www.vmware.com/pdf/vi3_301_201_san_cfg.pdf

RDM funciona únicamente con canal de fibra o iSCSI. En esta configuración, se utilizó una caja de almacenamiento SAN conectada a través del canal de fibra para asignar LUN a los hosts físicos. Estos LUN pueden asignarse a los invitados VMware mediante RDM. Se ha detectado que las reservas SCSI funcionan sin problemas con RDM (SCSI-2 Reserve/Release y SCSI-3). Estos dispositivos RDM podrían utilizarse como dispositivos compartidos entre los nodos de clúster. Sin embargo, también pueden funcionar como dispositivos locales para un nodo.

Un aspecto que se debe tener en cuenta es que los controladores SCSI virtuales para los sistemas operativos invitados deben ser distintos para los discos compartidos y locales. Se trata de un requisito de VMware cuando se comparten discos. El modo de compatibilidad de RDM para permitir acceso directo al almacenamiento desde el invitado debe ser "Físico". Para obtener información adicional, consulte la documentación de VMware ESX.

La Figura 1 (haga clic para ampliar) muestra una captura de pantalla de la configuración de almacenamiento en un host físico. Muestra los LUN desde el almacenamiento SAN que el ESX Server visualiza.


Figura 1. Configuración de almacenamiento (SAN a través de canal de fibra) en un VMware ESX Server

La Figura 2 (haga clic para ampliar) muestra una visión general del aspecto de la configuración de dispositivos para un sistema operativo Solaris invitado. Muestra que algunos dispositivos (discos duros) son LUN básicos asignados. Esto se realiza a través de RDM. Cada asignación RDM muestra el adaptador HBA virtual para el invitado (vmhba1 en este caso), el Id. de LUN del almacenamiento SAN que se está asignando (28 en este caso) y la ubicación de bus SCSI para dicho dispositivo (SCSI 1:0 para este invitado). Los discos que indican "Disco virtual" son dispositivos extraídos por la capa de VMware en el sistema operativo invitado. Tenga en cuenta que existen 2 controladores SCSI para el sistema operativo invitado. El controlador SCSI 0 se utiliza para los dispositivos locales y el Controlador SCSI 1 se utiliza para dispositivos que se comparten con otros invitados. Tenga en cuenta que el modo de compatibilidad para el dispositivo asignado RDM es "Físico". Esto permite garantizar que el sistema operativo invitado tenga acceso directo y sin restricciones al dispositivo.


Figura 2. Configuración de almacenamiento para un sistema operativo Solaris invitado

Para compartir dispositivos (asignados a través de RDM) entre invitados del mismo host físico, se debe activar "Compartir bus SCSI" en las "Propiedades de máquina virtual" para el controlador SCSI que se encarga de los dispositivos compartidos y establecerlo en "Virtual". En la Figura 2, el Controlador SCSI 1 de esta configuración sirve para compartir discos en hosts físicos. A continuación, seleccione "Utilizar un disco virtual existente" mientras agrega un disco duro y seleccione el archivo ".vmdk" para el dispositivo que se compartirá. Por ejemplo, la Figura 2 indica la ubicación del archivo .vmdk para "Disco duro 2".

Al compartir dispositivos asignados RDM entre sistemas operativos invitados de hosts físicos, debe establecerse la opción Compartir bus SCSI en "Físico", tal y como se muestra en la Figura 2, y asignar el mismo LUN del almacenamiento SAN a los hosts físicos que ejecutan VMware ESX. Al utilizar RDM, se asignaría el mismo LUN como dispositivos en todos los sistemas operativos invitados que necesiten compartir el dispositivo. Por ejemplo, el Nodo 1 de esta configuración ha asignado LUN ID 28 como "Disco duro 2". El mismo LUN debe asignarse como un disco duro en el resto de sistemas operativos invitados que tratan de disponer de LUN ID 28 como un dispositivo compartido con el Nodo 1.

En la Figura 3 (haga clic para ampliar), se muestra el sistema operativo Solaris invitado con los dispositivos agregados. El controlador "c1" cuenta con los 2 discos locales que aparecen en la Figura 2 y el controlador "c2" dispone de los discos compartidos.


Figura 3. Sistema operativo Solaris invitado que muestra dispositivos que se le presentan desde VMware ESX

Además de los dispositivos SCSI, los invitados pueden también utilizar dispositivos iSCSI o NAS. Su funcionamiento y configuración serían similares a los de una máquina Solaris normal.

III) Quórum
Se probaron ambos dispositivos de quórum del tipo SCSI y Quorum Server sin ningún tipo de problemas. No olvide que un dispositivo de quórum SCSI debe agregarse al invitado a través de RDM. El sistema operativo invitado debe tener acceso directo al dispositivo. Se espera que NAS Quorum funcione de forma similar.

IV) Redes
Las características de redes de VMware ESX Server son muy extensas. Gracias a los conmutadores virtuales, la compatibilidad de VLAN en conmutadores virtuales y la combinación de NIC, entre otros aspectos, las redes funcionaban sin problemas. De hecho, para estas configuraciones, se utilizó una única NIC en el host físico con el objeto de dirigir el tráfico para los sistemas operativos invitados. Incluía tráfico de interconexión público y privado en un caso de agrupación de clústeres. Sin embargo, se puede lograr la segregación en el nivel de conmutador virtual o el nivel NIC físico y sería ideal en un entorno de producción. Se puede contar con VLAN distintas (en el mismo conmutador virtual) para el tráfico público y privado o NIC físicas dedicadas asignadas a distintos conmutadores virtuales para cada tipo de tráfico.

Tenga en cuenta que el controlador "pcn", que se carga de forma predeterminada en Solaris con VMware, podría resultar un poco inestable. De modo que se recomienda la instalación de herramientas VMware en todos los sistemas operativos invitados Solaris para cambiar al controlador "vmxnet", que es bastante estable.

La Figura 4 (haga clic para ampliar) muestra una captura de pantalla de la configuración de red de un host físico. Muestra los distintos conmutadores virtuales y las NIC físicas asociadas, que se encargan del tráfico de las máquinas virtuales en un host físico. Cada conmutador virtual cuenta con un "Grupo de puertos de máquina virtual", que es la interfaz al mundo exterior de los sistemas operativos invitados. En una configuración de producción normal para el software Sun Cluster, se puede contar con un Grupo de puertos ("Red VM") para todo el tráfico de red público y otro Grupo de puertos dedicado ("Red de interconexión 1") para el tráfico de interconexión privado entre los miembros del clúster.


Figura 4. Configuración de red en un host físico que ejecuta VMware ESX Server.

En esta configuración, dado que contamos con todo el tráfico (público y privado) de los invitados Solaris agrupados en clústeres, desplazándose a través de un único Grupo de puertos, los adaptadores de interconexión pública y privada para el invitado muestran la misma "Red VM" en comparación con la Figura 2 que aparece anteriormente. Hemos sacado partido de la compatibilidad de NIC única para las interconexiones privadas. De esta forma, se podría dejar libre una ranura PCI en un invitado VMware, que es posible que el usuario desee utilizar para agregar más dispositivos en el sistema operativo invitado. La compatibilidad de NIC única estará disponible próximamente para los clientes en el parche de Sun Cluster 3.2.

Tenga en cuenta que el número máximo de ranuras PCI disponibles para cada sistema operativo invitado en VMware ESX Server 3.0.l es de 5. Esto equivale a el número total de NIC + controladores SCSI <= 5. Para obtener información adicional, consulte la documentación de VMware ESX.

V) Últimos comentarios
La configuración de hardware utilizada para este experimento:

  • 3 sistemas SunFire V20z de doble CPU (2 x 1,792 GHz) y con 4 GB de RAM, 1 disco local y adaptador QLA 2300 FC-AL para SAN.


  • Sun StorEdge 3510 para SAN, conectado a los hosts físicos a través de canal de fibra.


El clúster funciona de igual forma que un clúster normal. Hemos creado metaconjuntos/grupos de discos VxVM de Solaris Volume Manager y agentes de Sun Cluster configurados para que las aplicaciones cuenten con una alta disponibilidad. En resumen, el software Sun Cluster 3.2 se ejecuta en una configuración de VMware virtualizada, tal y como se esperaba, agrupando en clústeres sistemas operativos Solaris invitados y añadiendo otra dimensión a la capacidad de uso y disponibilidad. Si desea obtener una descripción general del clúster configurado, podrá encontrarla aquí.

Lamento que el post sea tan extenso, pero había un gran número de aspectos que eran necesario mencionar. Sus opiniones/comentarios son siempre bienvenidos.

Subhadeep Sinha.
Departamento de ingeniería de Sun Cluster.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.