Blog de Víctor M. Fernández

Evolucion del CLOUD COMPUTING !!!

2012-01-02T20:56:00.000+01:00

Han pasado mas de dos años desde que realice la siguiente ponencia publicada en este blog con anterioridad. Si bien es cierto que en aquel periodo inicial, la presentacion giraba en torno a la definicion de los distintos modelos (SaaS, PaaS e IaaS) del Cloud Computing, la posible aplicacion de los casos de uso de sus diferentes tipologias (publica, privada e hibrida) y una descripcion cualitativa de los riesgos previamente identificados.

Sin embargo, actualmente y fruto de la evolucion de estos años se han ido decantando fundamentalmente dos modelos, cada uno de ellos orientado a un tipo concreto de organizaciones:

- En el caso particular de las Pymes, la orientacion a la Nube Publica es mayor debido fundamentalmente al ahorro de costes tanto en la adquisicion del software como en el mantenimiento de la infraestructura y la posibilidad de utilizacion de los mismos recursos de infraestructura que las grandes organizaciones (computacion, red, almacenamiento, backup, etc...).

- En el caso concreto de las grandes organizaciones, la aproximación se esta produciendo en la orientacion interna al Servicio y a la trasformacion del Datacenter propio bajo el modelo de la Nube Privada.

Sin entrar a valorar las principales ventajas y beneficios del Cloud Computing (pago por uso, autoservicio y elasticidad) al igual que sus desventajas (garantias de seguridad de la información), si me gustaria destacar que la VIRTUALIZACION (aunque no es un requerimiento, como se puede apreciar en el modelo SaaS) si es la tecnologia habilitadora que esta permitiendo la evolución del modelo IaaS en base al siguiente recorrido: Nube Privada -> Nube Hibrida bajo un nuevo paradigma de adquisicion y entrega Servicios IT.

En este sentido, es de considerar la prevision que Marlon Molina expone en su blog, ya que mas alla de los cambios tecnologicos que estamos viviendo y su impacto en la gestion tecnica de la operativa diaria, este nuevo paradigma en la entrega de Servicios IT y el enfasis en la calidad del Servicio lleva consigo asociado de forma inevitable (nos guste o no) un importante cambio desde el punto de vista operativo en todo tipo de organizaciones sean de la naturaleza que sean, fundamentalmente debido a que esta orientacion a Servicio requiere una mayor gobernanza (ITIL, ISO 20000, etc...) alcanzable mediante la correcta implementacion de Servicios Gestionados, lo que igualmente obedece a una gestion mas eficaz y eficiente de la tecnologia.

Finalmente, aprovecho este articulo para identificar las soluciones existentes en la actualidad que permiten implementar nubes privadas y algunas de las citadas escalar a nubes hibridas bajo el ya mencionado modelo IaaS:

- VMWare vCloud
- OpenStatck (a destacar la implementacion de StackOps)
- RedHat Cloudforms
- Xen Cloud Platform
- CloudStack

Datacenter Activo - Activo con VIRTUALIZACION - parte III

2011-12-11T19:48:00.001+01:00

Finalmente y como continuacion a la parte I y la parte II de esta serie de articulos (de vital importancia la relaccion entre la Gestion de la Disponibilidad y la Gestion de la Continuidad), en esta ocasion me gustaria destacar las principales ventajas que aporta la VIRTUALIZACION DEL ALMACENAMIENTO desde el punto de vista del negocio:

Como bien indica Josep Ros en su blog, esto es especialmente importante debido fundamentalmente a que los Virtualizadores de Almacenamiento se van a encargar de realizar toda la logica de la gestión del almacenamiento (salvo la parte evidente de los switches de la SAN), donde destaca la generacion y entrega de las LUNs creadas entre distintas cabinas de diferentes fabricantes incluyendo nuevas funcionalidades propias del frontend de dichos sistemas de almacenamiento como es el caso del Thin Provisioning. Esto repercute directamente en que las cabinas de almacenamiento de proposito general puedan ser de un menor nivel [al margen de nuevas funcionalidades propias del backend de dichos sistemas de almacenamiento como son: tiering (dinamico o manual) de LUNs o de bloques, compresion de datos, controladoras activo-activo, multiprotocolo (FC, FCoE, iSCSI, NFS, CIFS), etc...]

Sin embargo, en el caso concreto que nos ocupa (Datacenter Activo - Activo en un entorno de Produccion de Virtualizacion de Servidores) este nuevo enfoque supone una importante oportunidad de mejora con respecto al primer y segundo escenarios descritos anteriormente.

El en primer escenario la implementacion de los Virtualizadores de Almacenamiento va a permitir que con un correcto diseño y configuracion de la arquitectura logica de almacenamiento sea posible resolver el punto de fallo que suponia la caida de la cabina como almacenamiento compartido del cluster extendido de los hypervisores. La oportunidad de mejora consiste en la utilizacion de los dispositivos de bloques (discos FC, SSD, SAS, SATA) de cada una de las cabinas que residen fisicamente en cada uno de los CPDs de forma conjunta y balanceada en el proceso de generacion y entrega de las LUNs como Datastores compartidos. Nota importante la configuracion en Alta Disponibilidad de los propios Virtualizadores de Almacenamiento ubicados fisicamente cada uno de ellos en uno de los CPDs implicados.

En el segundo escenario la implementacion de los Virtualizadores de Almacenamiento representa una menor oportunidad de mejora ya que en este caso el diseño y configuracion de la arquitectura logica de virtualizacion y almacenamiento esta ideada en base a la disposicion local con pesos del 50% de los productos que corren en las VMs implicadas directamente en la prestacion del servicio.

En base a mi experiencia en clientes destaco los siguientes Virtualizadores de Almacenamiento mas conocidos:

Datacenter Activo - Activo con VIRTUALIZACION - parte II

2011-12-04T21:33:00.001+01:00

Como continuacion al anterio articulo de este blog, en este post me gustaria dar un enfoque diferente a como se aborda de forma tradicional la Gestión de la Continuidad y su viculacion con la Gestion de la Disponibilidad dentro del alcance de un proyecto de Virtualizacion de Servidores o/y en el caso de un proyecto especifico a tal efecto y/o finalmente dentro de la explotacion de un servicio; con el conocido software VMWare Site Recovery Manager.

Son muchas y conocidas las ventajas que aporta este tipo de software en los referente a la VIRTUALIZACION, como es la integracion con los distintos sistemas de almacenamiento multivendor (EMC, NetApp, IBM, etc...) de proposito general ya sean cabinas de tipo SAN (protocolos FC, FCoE) o dispositivos NAS (rotocolos CIFS, NFS, iSCSI) y sobre todo por la naturaleza de los servidores implementados como maquinas virtuales (VMS) la posibilidad de gestionar y automatizar un plan de recuperacion ante desastres de una forma mucho mas agil, dinamica y funcional que una prueba de contingencia en un entorno fisico, tal y como se puede apreciar en las imagenes adjuntas.

Sin embargo, al margen de su coste una de sus posibles desventajas reside en la naturaleza misma de dicho producto, debido a que esta diseñado y desarrollado para implantar planes de contigencia en el caso concreto de un escenario de DATACENTER ACTIVO - PASIVO lo que esta relaccionado directamente con la replicacion (normalmente sincrona, al margen de si la fibra es oscura y dedicada o multiplexada a través de equipos DWDM) entre dos sistemas de almacenamiento ubicados cada uno de ellos en un CPD diferente actuando el pricipal como origen del entorno de Produccion y el secundario como destino (directamente relaccionado con los dos indicadores de gestion fundamentales en este aspecto de las infraestructuras: RTO y RPO).

Por otro lado, para implementar un plan de recuperacion ante desastres (es decir un DRP: Disaster Recovery Plan) como parte tecnologica dentro de un plan de continuidad de negocio (es decir BCP: Business Continuity Plan) es posible analizar otras opciones que pasan por la generacion de una SAN extendida (de tipo FRABRIC) y una LAN extendida entre los distintos CPDs implicados; contituyendo asi un DATACENTER ACTIVO - ACTIVO tal y como se puede apreciar en la imagen final del escrito.

En un primer escenario, es especialmente importante la configuracion de un cluster extendido (HA, DRS) entre los hypervisores de cada CPD con su propio sistema de almacenamiento como Datastore compartido entre ambos centros de datos, pero ubicado y funcionando unicamente en uno de ellos. Este es precisamente el punto de fallo de mayor impacto ya que la caida de la cabina de almacenamiento requiere que se disparen procesos de respaldo tradicionales ya sean manuales o automatizados lo que implica la aceptacion de un tiempo de parada en la prestacion del servicio y su posterior restablecimiento con un rendimiento al 100%. Sin embargo la posibilidad de mover servidores (VMs) entre los sites implicados supone una ventaja a considerar.

En un segundo escenario, es especialmente importante el balanceo de carga y la alta disponibilidad de los productos que se ejecutan en las maquinas virtuales (VMs) dentro de cada cluster local de hypervisores, ya que se debe ser especialmente riguroso para conseguir una distribucion donde los pesos de los dos sitios sean del 50% con su propio sistema de almacenamiento como Datastore no compartido entre ambos centros de datos. La ventaja principal reside en que el servicio no solo esta protegido ante la caida de los hypervisores que conforman el cluster local, sino que ademas esta cubierto ante la caida del sistema de almacenamiento de forma directa sin la necesidad de activar ningun proceso ya sea este de tipo automático o manual y sobre todo sin suponer en ningun caso la parada en la prestacion del servicio. La desventaja consiste en la perdida de rendimiento ya que el 50% de los servidores (VMs) que daba servicio esta caido y unicamente se presta el servicio por el otro site que aporta el 50% de la capacidad de procesamiento. Este ultimo esquema es compatible con soluciones que automatizan planes de contingencia tradicionales como hemos visto, aunque no seria necesario si ante una situacion de contingencia esta validada y prevista la prestacion del servicio con la mitad de rendimiento.

Otra de las buenas practicas (compatible con ambos escenarios descritos) que esta directamente relacciona con la Gestion de la Configuracion ante planes de contigencia y de recuperacion ante desastres en un entorno de VIRTUALIZACION es la agrupacion de los servidores (VMs) que prestan un determinado servicio de forma completa en Aplicaciones Virtuales (vAPPs) y la asignacion de una LUN dedicada a dicha vAPP, siempre y cuando no sea un requerimiento de los productos que corren en las VMs la asignacion dedicada de la LUN (RDM).

Convergencia de ALMACENAMIENTO y VIRTUALIZACION !!! - Parte III

2011-10-23T14:04:00.000+02:00

A raiz de la noticia que se ha trasmitido a la prensa especializada acerca de la discontinuidad de los equipos mas tradicionales de almacenamiento de EMC como son el EMC Celerra y EMC Clariion en pro de la potenciacion de los nuevos equipos EMC (tras la reciente adquisicion de la compañia Ipsilon) del tipo VNX/VNXe es importante destacar las herramientas de gestión y su integración en la plataforma de Virtualizacion de Servidores.

Como ya vimos en la primera parte de esta serie de articulos (multisolucion de fabricante de hypervisor y multivendor de sistema de almacenamiento), la integración de las soluciones de almacenamiento de NetApp (sistemas basados en DataOntap) y EMC (sistemas de tipo Celerra, Clariion y Symmetrix) es mas que relevante en cuestión de los protocolos mas comunes de almacenamiento (NFS, iSCSI, FC y FCoE con la llegada de vSphere v5.0) en el caso concreto de VMWare vSphere.

Sin embargo, como se puede apreciar en las imagenenes adjuntas dicha integración es igualmente posible con los sistemas de almacenamiento de otros fabricantes como es el caso de IBM, HP y Dell. Cada uno de ellos con sus propias ventajas e inconvenientes en la integración con plugins dentro de vCenter como herramienta unica y centralizada de administración del hypervisor (hosts), VMs (maquinas virtuales), almacenamiento (NAS/SAN), backup (VDR) y redes (vSwitch y VDS).

En estos escenarios multivendor de integración de soluciones de Almacenamiento en entornos de Virtualización de Servidores, se hace cada vez mas preciso y necesario incorporar tanto una gestión de la capacidad como una gestión de la configuración eficaces, basadas en procesos y alineada con las buenas practicas de la gestión de Servicios.

En el caso concreto de los nuevos sistemas de almacenamiento VNX/VNXe dicha integración es bidireccional (tanto desde el vCenter con destino el sistema de almacenamiento, como desde la propia consola de Unisphere con destino el hypervisor), tal y como se puede apreciar en el video adjunto con respecto a la creacion/eliminación/modificación de Datastores (NFS e iSCSI), asignación de LUNs, Politica de Multipath, Thin Provisioning, Deduplicacion, Snapshots y Tiering de discos (SAS y SATA).

Sin considerar otras ventajas, el mayor beneficio inmediato de este tipo de integración reside en la disminución de la complejidad en la provisión de disco a los hypervisores, al mismo tiempo que incrementa la flexibilidad y versatilidad en la gestión de las maquinas virtuales (VMs) y por extension la mejora en la disminución de los tiempos de puesta en produccion de la infraestrucutra necesaria para el aprovisionamiento de nuevos servicios.

Impacto de la VIRTUALIZACION en la Gestión de Servicios - ITIL

2011-08-22T11:35:00.014+02:00

Es habitual en los proyectos de implantación de la infraestrucutra de una plataforma de virtualizacion (de servidores o de escritorios) ya sea mediante la metodologia PMBOK o PRINCE2 el camino critico que representa el proceso P2V (Physical To Virtual) previo assesment de cada uno de las maquinas/escritorios que queremos implantar en la nueva plataforma compartida en almacenamiento y backup.

En este sentido resulta mas que interesante todas y cada una de las nuevas funcionalidades de los diferentes productos de mercado:

- VMware vSphere 5 (Auto Deploy, vSphere Storage Appliance (VSA), Web Client, vCenter Server Appliance (Linux), Storage DRS, FCoE support, Virtual Hardware 8, Storage Profiles, Driver Storage Providers, Secure Syslog, Dump Collector, VMFS5, VDS5, Enhanced Firewall, etc...)

- Citrix XenServer 5.6 (Snapshots Commit & Rollback, Dynamic Workload Balancing, Integrated StorageLink, Distributed Virtual Switching, Web Self Service, etc...)

- RHEV 3.0 (V2V Migration, OVF Import / Export, Dedicated Monitoring & Reporting, VDI Support, Power User Portal (Autoservice), RHEV-Manager Java application, RHEL 6 based, etc...)

- HyperV 3.0 (Cluster Shared Volumes, Storage and network resource pools, Bandwidth Management, Virtual Switch Extensions, etc...)

Sin embargo, desde el dia despues de la entrega del proyecto y su paso a produccion comienza la explotación de esta nueva plataforma que debemos enmarcar dentro del marco de trabajo de la Gestión de Servicios y de las buenas practicas de ITIL teniendo en cuenta todas y cada una de las recomendaciones realizadas en este blog (Gestión del Virtual Sprawl, Gestion de la Capacidad, Gestión de la Configuración, Gestión de la Disponibilidad, etc...).

En este sentido, en el articulo se representan desde el punto de vista cualitativo cada uno de los 34 aspectos mas relevantes de la Virtualizacion y si el mismo supone una Ventaja (V), Desventaja (D) o Riesgo (R) a considerar. Posteriormente, del mismo modo se propone un analisis cuantitativo de esos mismos aspectos con una valoración del 1 (bajo impacto) al 4 (alto impacto) sobre los 6 aspectos troncales (Capacidad, Gestión, Disponibilidad, Coste y Seguridad).

Finalmente, se muestra una tabla de mapeo basada en la correlacion de cada uno de los 34 aspectos mas relevantes indicados anteriormente acerca de la VIRTUALIZACION con la mayoria de los procesos tanto de la parte de soporte al Servicio (Service Suppport) como de entrega de Servicio (Service Delivery) de ITIL v2.

Como conclusion, indicar que el impacto de los aspectos listados (18) de gestión y disponibilidad de la virtualización es alto con respecto al resto. Asimismo con un mayor detalle, los procesos de gestión finaciera, gestión de niveles de servicio, gestión de la continuidad y gestión de la disponibilidad son aquellos en los cuales el impacto de la virtualización es significativo.

¿Como combatir el VIRTUAL SPRAWL?

2011-07-25T17:36:00.010+02:00

Tras un proyecto de implantación de una infraestructra de Virtualizacion de Servidores con su solucion integrada de gestión de Almacenamiento (SAN ó NAS) y Backup (VTL ó Libreria de Cintas) o más aun tras el proceso P2V que suele ser el driver de este tipo de proyectos, desde el dia despues de su paso a producción una de sus mayores justificaciones y/o ventajas comienza a ser su gran paradijma. Me refiero a la rápida capacidad de la nueva infraestructura virtual de provisionar VMs (Virtual Machines) es decir disminuir de forma considerable el "time to service" de un Servicio Informático o el "time to market" de un proveedor de Internet.

En la mayoria de los clientes que he podido visitar, el crecimiento indiscriminado sin seguimiento ni control de la proliferación de VMs comienza a ser un problema no solo en cuanto al espacio en disco ocupado en el sistema de Almacenamiento (lugar donde residen las VMs y su snapshots realizados con vCenter, independientemente de su capacidad de "Thin Provisioning", "Deduplicación" y "Tiering"), en el sistema de Backup (Librerias de cintas tradicionales o VTLs con "Deduplicación offline") sino por el riesgo operativo que supone esta situación.

Existen 3 lineas de trabajo a desarrollar para combatir dicho crecimiento descontrolado de VMs:

1.- Gestión de la Configuración
2.- Gestión de la Capacidad
3.- Gestión de la Seguridad

En el primer caso, podemos recurrir a heramientas comunes de gestión de la configuración, las cuales deberian proveernos de lineas base capaces de comparar en el tiempo este tipo de crecimiento e identificar las nuevas VMs; aunque en el caso concreto de VMWare vSphere (ESX y/o ESXi) existen herramientas de ecosistema como v-Scout o su nueva versión v-Commander las cuales permiten identificar las VMs con atributos personalizados e incluso generar politicas activas tras llegar al fin del ciclo de vida de cada una de las VMs. De hecho en esta linea ya esta trabajando el propio fabricante VMWare como se puede apreciar con: vCenter Configuration Manager y vCenter Discovery Manager.

En el segundo caso, resulta esencial trabajar en la linea de la gestión de la capacidad ya que será la herramienta que permitirá diagnosticar el consumo de infraestructura mas alla que la propia alta-disponibilidad intrinseca de los entornos virtuales. Esta es una de las actividades menos desarrolladas y con mayor efectividad y esta directamente relaccionado igualmente con la monitorización en Virtualización.

El tercer y ultimo caso de las medidas para disminuir este riesgo, reside en la correcta configuración de las directivas de permisos y privilegos de los usuarios locales o remotos (si estan mapeados los permisos contra un determinado Directorio Activo) en lo que se refiere a las politicas de seguridad de vCenter. Es decir restringir la capacidad de los usuarios para crear VMs, clones, templates y snapshots de las mismas.

Este tipo de medidas son especialmente relevantes en aquellas organizaciones IT que ya han comenzado a tras sus primeros pasos hacia el modelo de nube privada y/o nube hidrida dentro del Cloud Computing, aunque cobra su maximo exponente en el caso de la nube publica y aquellos proveedores que utilizan infraestructuras compartidas con multipropiedad (mas conocido como multitenancy) para albergar a sus clientes.

Gestion de la Configuración - CMDB (ITIL)

2011-07-25T14:09:00.012+02:00

Dentro de la Gestión de Servicios y mas aun en el mundo de los Servicios Gestionados, al margen de si se constituye una Oficina de Servicio dedicada a velar por la funcion y garantia de ó de los Servicios o si se gobiernan de otra forma mas departamental y por extension mas jerarquica y tradicional; la gestión de la configuración es una de las piezas mas importantes en la gestión de los activos de informacion y su pieza angular sobre la que pivota toda la informacion es la CMDB (Configuration Management DataBase).

Como ya se mostró en la siguiente presentación, al margen de los cambios organizativos que supone la aparición de roles con responsablidades funcionales y la resistencia a este nuevo modelo donde la dependencia organica aporta poco valor; OneCMDB es una herramienta Open Source que proporciona de serie funcionalidades de descubrimiento y carga de Elementos de Configuración (CIs: Configuration Items).

En los proyectos de implantación de una CMDB, mas alla del correcto diseño del modelo de datos una de las tareas que se representa en el camino critico es la carga inicial de activos y su posterior mantenimiento. En este caso concreto OneCMDB proporciona de serie la integración con NMAP para realizar el descubrimiento y al mismo tiempo y de forma compatible la integracion con NAGIOS en cuanto a la incorporación de aquellos componentes que estan siendo monitorizados, lo cual representa una alternativa mas que valida en consideracion con otros productos de mercado.

Finalmente es un hecho conocido que el éxito o fracaso de este tipo de proyectos se basa fundamentalmente en el hecho de no morir de exito, es decir, es preferible tener identificadas aquellas aplicaciones que utilizan mayoritariamente los usuarios y sobre las mismas realizar un mapeo similar a este modelo sencillo: APLICACION (atributos de definición y de utilización) -> SOFTWARE BASE (atributos de definición y utilización de web server, j2ee server, bbdd server, ldap server, etc...) -> HARDWARE BASE (atributos de definición y de utilización de servidor, sistema operativo, interfaces de LAN, LUNs de cabina de discos, DRIVES de robotica de backup, etc... ) -> HARDWARE COMUN (atributos de definición y utilización de redes LAN, redes SAN, cabinas de discos, robótica de backup, etc...); al hecho de tener que configurar de forma completa un Catalogo de Servicios con sus diferentes Niveles de Servicio y en base a los mismos empezar a diseñar el modelo de datos que dará soporte a la CMDB.

Backup en entornos de VIRTUALIZACION !!!

2011-06-25T11:36:00.013+02:00

Del mismo modo que ya comentamos como la monitorización es una de las piezas mas olvidada dentro de los proyectos de implementación de un plataforma de Virtualizacion en la que de forma progresiva se comienza realizando un proceso de P2V de aquellos servidores x86_x64 que ya no tiene sentido mantener standalone y posteriormente de forma gradual se van incorporando servicios mas criticos a la misma; lo mismo sucede con el backup.

Esto suele ser debido a que el objetivo principal del proyecto se basa en la miración de todos esos servidores x86_x64 que se han decidido decomisar tras el correcto P2V a la nueva plataforma de Virtualizacion. Sin embargo, como suele ocurrir el dia despues de la puesta en produccion de la plataforma (prestación de Servicio) comienza a ser vital no solo cubrir su monitorizacion sino igualmente el backup de las VMs que estan alojadas en la cabina de almacenamiento o dispositivo NAS, maxime cuando la idea que reside tras una inverson similar es evolucionar la plataforma para sacarle el maximo partido posible con el proposito de amortizar la inversion.

Dicho esto, dentro del mercado en el caso particular de VMWare vSphere existe un ecosistema de soluciones de backup entre los cuales Veeam Backup y Quest vRanger gozan de un mayor reconocimiento y base instalada. Lo mismo sucede en el caso concreto de Citrix XenServer con la solucion PHD Virtual Backup entre otras muchas.

Sin embargo, a titulo personal he podido apreciar como en las grandes compañias y en las corporaciones resulta poco habitual encontrarse con este tipo de soluciones de backup mas orientadas al ecosistema de cada hypervisor y backup a disco. Es por esto que dicho articulo se centra en la integración de una solucion de mercado de tipo enterprise como puede ser Symantec Veritas NetBackup compatible en todo momento con una infraestrucutra tradicional de libreria de cintas como con una infraestrucutra de tipo VTL al igual que una infraestrucutra mixta de tipo VTL frontend y libreria de cintas backend.

Como todo fabricante, en su ultima versión (NBUv7) aparece todo un listado de nuevas funcionalidades entre las que se resaltan la compresion y deduplicacion en origen, el backup de grano fino, la integración con las plataformas de virtualizacion mas habituales, etc... Con respecto a VMWare vSphere (ESX/ESXi), como se puede apreciar en los pantallazos adjuntos se posibilita la integracion directa con la herramienta de gestión Virtual Center (compatible tanto para ESX como ESXi) y la creación de politicas comunes (igualmente ESX/ESXi) a traves de snapshots propias de las maquinas virtuales (VMs) definidas. Asimismo se permite un backup de grano fino de tipo sin agente (agentless) en el caso de los sistemas operativos RedHat Enterprise Linux y Suse Enterprise Linux.

Finalmente, para aprovechar la nueva funcionalidad de compresion y deduplicacion de datos en origen (lo que por otro lado deberia representar una importante ventaja en lo que supone la ventana de backup por LAN), en principio resulta necesaria la instalación del agente de NetBackup dentro del sistema operativo propio de la maquina virtual (VM) maxime cuando no se trata de las opciones anteriormente citadas con respecto a la copia de seguridad de grano fino a traves del API de vCenter.

Fuente origen: Angel Ferras

Oficinas de Servicio (ITIL) en WHYFLOSS 11

2011-06-25T10:44:00.012+02:00

Dentro del marco de la celebración de la Conferencia Internacional WHYFLOSS 2011 que se celebro en las instalaciones de Madrid del IE (Instituto de Empresa), tuve el placer de poder participar como ponente exponiendo la alternativa que supone en todo momento la constitucion e implantación de una Oficina de Servicio de tipo LOW COST mediante la utilización e integración de herramientas Open Source.

El cuerpo principal del mensaje de la ponencia se basa en la idea que el objetivo principal de una Oficina de Servicio debe ser velar por la funcion y la garantia del Servicio a lo largo de sus fases de Transicion y Operación basandose periodicamente en la identificación e implemetación de planes de mejora.

Mas alla de las herramientas y de los cambios organizativos (aparicion de nuevos roles); resulta de vital importancia la correcta definicion e implantación no solo de un modelo de relaccion sino mas aun de un modelo de gestion adecuado que permita en todo momento aportar valor al cliente/s y evidenciar la calidad del Servicio que se esta prestando. Este control y seguimiento se convierte imprescindible si ademas de este objetivo principal se persigue la certificación de la ISO 20000 y el mantenimiento de dicha certificacion.

PONENCIAS:
http://www.whyfloss.com/es/conference/madrid11/speakers

Oficina de servicio_low_cost_itil

View more presentations from Victor M. Fernandez.

Monitorizacion de entornos en VIRTUALIZACION !!!

2011-02-20T19:02:00.017+01:00

Una de las partes en la que menos enfasis se realiza normalmente en los proyectos de migracion ó implantacion de infraestrucutruas de Virtualizacion (sea de Servidores o de Escritorios) reside en el aspecto de la Monitorizacion. Sin embargo, desde el primer momento de su puesta en produccion y de la responsabilidad de la gestion de la explotacion de este nuevo entorno virtual (dentro del Datacenter) comienza a ser critico todo aquello relaccionado con la monitorizacion; maxime si el servicio esta dentro del marco de las buenas practicas de ITIL o mas aun el cumplimiento de la ISO 20000.

En este sentido, los productos de Virtualización (ya vimos que es posible realizar Virtualizacion de Servidores sin la necesidad de la figura del hypervissor aqui) basados en los hypervisores mas conocidos del mercado como son VMWare vSphere, Citrix XenServer y RHEV permiten su monitorizacion directa o indirecta mas alla del contenido de las VMs (Maquinas Virtuales) que permiten ejecutar.

En el caso de vSphere ESX, XenServer y RHEV es posible realizar su monitorizacion mediante software tradicional de monitorizacion de infraestructuras fundamentalmente basado en el modelo cliente/servidor como son: Nagios, Zabbix, Hyperic, Zenoss, etc. o por el contario a traves del protocolo SNMP (indispensable con vSphere ESXi) como por ejemplo con Cacti tal y como es posible apreciar en las imagenes adjuntas.

Sin embargo en el caso concreto de vSphere ESX/ESXi es posible recurrir a software denominado del ecosistema de VMWare como es el caso tanto de Quest como de Veeam.

La diferencia fundamental de este tipo de software de ecosistema VMWare con respecto al software tradicional de monitorizacion, reside en que el primero de ellos utiliza directamente llamadas a la API de vCenter lo cual no resulta nada intrusivo (no hay necesidad de instalar ningun tipo de agente) ni requiere la modificacion de las politicas de seguridad a nivel de firewall interno) de los hypervisores citados anteriromente.

Por otro lado, volviendo al caso particular de vSphere ESX/ESXi, la integración del software de ecosistema de VMWare (Veeam y Quest) con respecto a la monitorizacion es total y permite el descubrimiento automatico de todos los elementos del vCenter: Cluster de ESX, hosts de ESXi standalone, vAPPs (Virtal Applications) como conjunto logicos de VMs (Virtual Machines), VMs, Datastores, etc. como es posible apreciar en las imagenes adjuntas.

En esta ultima linea de trabajo, en la monitorizacion de la evolucion del consumo de disco por parte de todos y cada uno de los diferentes Datastores del vCenter, es posible conocer dicha evolucion no solamente de los Datastores locales sino igualmente de los remotos como dispositivos de bloques (ya sea via FCP o iSCSI) o sistemas de ficheros (NFS, CIFS) esten o no esten en uso. Detalle de la imagen adjunta con cabinas/NAS de NetApp y EMC.

Convergencia de ALMACENAMIENTO y VIRTUALIZACION !!! - Parte II

2011-02-08T18:22:00.041+01:00

Mas allá de la integración, en el caso de la Virtualizacion de VMWare vSphere, con las tecnologias de Almacenamiento de fabricantes como NetApp y EMC como se puede apreciar en este anterior articulo, dicha integración es posible igualmente con otros productos de Virtualización como Citrix XenServer objeto de este nuevo post.

Dicha integración no solo proporciona información en la gestión de la infraestructura virtualizada acerca del almacenamiento utilizado con el maximo nivel de detalle; un correcto alineamiento de los bloques de datos, sino que ademas permite utilizar las funcionalidades de tercera copia propias del sistema de almacenamiento como puede ser el uso de snapshots y clones compatible en todo momento con las capacidades de replicación (mayoritamente sincrona) a nivel hardware y mas que interesantes en el ciclo de vida de las VMs (Maquinas Virtuales).

Como se puede apreciar en los pantallazos adjuntos (Detalle: cluster de dos hypervisores XenServer en HA con acceso compartido a una cabina de discos de proposito general de NetApp que ejecuta DATAOntap), la herramienta de gestión XenCenter permite conectar directamente con cada uno de los agregados y crear Storage Resources directamente especificando incluso el numero de volumenes a crear en la cabina y si estos son servidos con funcionalidades avanzadas como Thin Provisioning y Deduplicacion.

En paralelo, desde la herramienta StorageLink es posible descubrir la configuracion existente del Datacenter virtual, incluyendo el detalle acerca del estado de las VMs y las posibles plantillas existentes o generadas. Asimismo, se permite declarar la configuración de la cabina utilizada donde residen las VMs proporcionando información en base a la utilización de dicho sistema de almacenamiento al igual que la posibilidad de generar nuevos Storage Resources en la infraestrucutra de Virtualización directamente desde los propios agregados de la cabina de discos; posibilitando incluso el hecho de poder especificar igualmente aquellas funcionalidades avanzadas como Thin Provisioning y Deduplicacion y el propio protocolo de almacenamiento FCP/iSCSI.

Finalmente, una de sus funcionalidades menos conocida pero no por ello menos importante, reside en la capacidad como complemento añadido a dicha herramienta de soportar de serie la opcion de diseño y creacion de forma guiada de un plan automatizado de Contigencia del entorno Virtual. Normalmente este "Disaster Recovery Plan" (DRP) formaria parte del "Business Continuity Plan" (BCP) que representa un nivel superior al tecnologico.

La configuracion de este Plan de Contigencia se realizaria por fases como se puede apreciar en la imagen adjunta. En una primera fase seria necesario realizar todas las tareas guiadas sobre el Datacenter Virtual en el SITE principal (normalmente el que da servicio) para lo cual es requisito indispensable tener conectividad IP con el SITE secundario (tanto de la infraestrucutra de Virtualización como la de Almacenamiento).

En una segunda fase posterior, seria necesario realizar igualmente las tareas guiadas sobre el SITE secundario (el que daria servicio ante una caida del principal), lo que incluiria las pruebas funcionales del plan de Contigencia generado y por extencion la puesta en marcha del failover entre SITES de forma automatizada.

Destacar que en las ultimas versiones de XenServer, se ha incorporado StorageLink como parte del core de dicho producto de Citrix al igual que un buen numero de mejoras representativas entre las que seria necesario destacar: Web Self-Service y Distributed Virtual Switching como indica la release notes.

"Capacity Planning" en entornos FISICOS y VIRTUALES

2011-01-09T14:20:00.023+01:00

Al igual que la fase de diseño resulta de extraordinaria importancia en los proyectos de implantación y/o migración de infraestructura de servidores, almacenamiento y backup en lo que se conoce como conjunto de medidas para evitar en la medida de lo posible la desviación del camino critico; en la explotación del Datacenter la gestión de la capacidad resulta si cabe de mayor relevancia por aquello que dicha infraestructura condicionara el servicio que se entrega directamente a los usuarios en el dia a dia de la operaciones y la futura evolución tanto del Datacenter como del Servicio que se presta.

Al margen de la necesidad de invertir en la gestión a nivel de proceso de la capacidad de cada uno de los servicios que se prestan maxime cuando la infraestructura citada anterormente es compartida, seria mas que positivo considerar la posibilidad de aqduirir una herramienta que posibilite medir de forma sencilla y eficaz la evolución de la infraestructura en la que se apoyan los servicios que ofrece el Datacenter con el animo de intervenir como elemento facilitador en la toma de decisiones en base al control y seguimiento periódico que hay que realizar.

Como se puede apreciar en los pantallazos adjuntos, la posibilidad de poder gestionar igualmente infraestructuras fisicas y virtuales tanto de servidores, como de sistemas de almacenamiento y de backup puede representar mas que una ventaja competitiva en este sentido.

En el caso particular de la Virtualizacion de Servidores implementada con vSphere (ESX/ESXi) de VMWare se deberia permitir la gestión de la capacidad no solo de cada uno de los hosts (mas conocidos como hypervisores) sino ademas de las agrupaciones logicas en modo cluster de los mismos al igual que las VMs (Maquinas virtuales) contenidas o no en vAPPs (Aplicaciones Virtuales) todo ello dentro del ámbito del Datacenter Virtual. Como se puede apreciar en la imagen anexa, se deberia posibilitar igualmente la identificación y evolución de todos y cada uno de los DataStores asociados.

Del mismo modo en el caso concreto de los sistemas de almacenamiento tanto cabinas de discos de proposito general (FCP e iSCSI), como dispositivos de tipo NAS (NFS y CIFS) multifabricante (EMC, NetApp, Sun Microsystems) deberia ser posible medir su evolucion y consumo maxime cuando estan habilitadas las nuevas funcionalidades de Thin Provisioning y Deduplicación online ya que cobra especial relevancia la sobresuscripción y por extencion el posible compromiso del disco logico ofrecido a los sistemas y el disco fisico libre del almacenamiento global.

Para finalizar, con respecto a los sistemas de backup de tipo software mas conocidos en el mercado (Backup Exec, NetBackup, TSM, Commvault, Legato, ARC Serve) tanto si estan basados en las tradicionales librerias fisicas de cintas, como si estan basados en las nuevas VTLs con o sin backend de discos y/o con o sin backend de cintas; deberia ser posible medir la evolución del consumo de GBs, de cintas fisicas y/o drives logicos al mismo tiempo que el rendimiento de los trabajos que son necesarios respaldar en referencia a las distintas politicas de seguridad configuradas. Asimismo, es de remarcar que en cuanto a las VTLs formaria parte de la gestión de su capacidad la medida de la evolución de su ratio de deduplicación y la diferencia entre el espacio nominal y el espacio fisico consumido de manera conjunta a la evolución del uso de la caché.

Al igual que el resto de articulos orientados a la gestión unificada y convergente de las infraestructuras de Almacenamiento y Virtualización, un correcto y periódico "Capacity Planning" representa mas que un avance en la evolución de la Explotación del Datacenter hacia el camino de la nube privada o "Cloud Privado" como fase previa de la nube hibrida en la gestión IT.

"Best Practices" en gestión de ALMACENAMIENTO con VIRTUALIZACION

2010-12-31T12:18:00.025+01:00

Un nivel superior en la convergencia de la gestión conjunta de las infraestructuras de Almacenamiento y Virtualización lo representan las buenas practicas.
Se basan en la necesidad de orquestar cambios organizativos mas allá que la integración de los productos de Virtualización de VMWare, Citrix y RedHat (basados en la figura del hypervisor, OJO que es posible virtualizar servidores sin hypervisor como ya se indico en este blog) con los productos de los fabricantes de Almacenamiento como NetApp, EMC y Sun Microsystems como ya se trató anteriormente en este anterior articulo.

El objetivo de dichas buenas practicas se centra en el requisito que supone el hecho que los administradores de Virtualizacion y los administradores de Almacenamiento trabajen conjuntamente para lograr una mayor eficiencia, control y seguimiento en la explotacion del Datacenter. La idea se basa en evitar los errores de una de las consecuencias mas comunes de la gestión de los entornos virtuales, como es la proliferación sin orden ni criterio de las VMs (Maquinas Virtuales)... mas conocido como VIRTUAL SPRAWL.

Dentro de lo que se conoce como ecosistema VMWare (vSphere: ESX/ESXi) seria necesario considerar la posibilidad de aqduirir una herramienta que posibilite mostrar e identificar de un modo end-to-end la configuración vigente desde la propia VM (Maquina Virtual) hasta el conjunto de bloques (FCP e iSCSI) y ficheros (NFS, CIFS) pasando por todas las rutas I/O a cada Almacenamiento fisico utilizado pudiendo ser cabinas de disco de proposito general o dispositivos de almacenamiento de tipo NAS.

Como se puede apreciar en los pantallazos adjuntos es posible identificar tanto en el lado del Almacenamiento todos aquellos componentes necesarios en la gestión de la/s cabina/s y/o dispositivo/s NAS (RAID, grupos de discos, discos fisicos, volumenes, LUNs, ficheros, etc.), como en el lado de la SAN (Switches de tipo FC como iSCSI) al igual que todos y cada uno de los componentes de los Virtual Datacenters como son los Clusters de hypervisores ESX/ESXi, hosts standalone del mismo tipo ESX/ESXi asimismo como los Datastores utilizados por cualquiera de los protocolos citados.

En el caso concreto y particular de cada una de la VMs (Maquinas Virtuales) se posibilita el conocimiento de su camino fisico y su camino logico desde su host owner (en la arquitectura del Datacenter) hasta el LUN exacto del Almacenamiento que utiliza como Datastore asociado. Del mismo modo que si dicha VM se encuentra en una vAPP (Aplicacion Virtual) como conjunto de VMS desplegadas en un unico cluster como agrupación de varios nodos del tipo hosts ESX/ESXi.

El fondo de toda esta gestion integrada y convergente de las infraestructuras de almacenamiento y virtualización, lo que se persigue es un escalón mas en el ciclo de vida de la evolución del Datacenter hacia lo que se conoce como nube privada o cloud privado como paso previo hacia la expansión a la nube hibrida para poder aprovechar sus capacidades de elasticidad y disponibilidad ante determinadas situaciones bajo demanda, como se puede apreciar en el resumen inferior de dicho post:

Novedades en VIRTUALIZACION !!!

2010-12-20T10:34:00.021+01:00

Este articulo se centra en el cambio que supone en la ejecución de proyectos y en las operaciones de la infraestrucutra virtualizada del Datacenter de las organizaciones, el anuncio que ha realizado VMware en el cual trasmite para las proximas versiones la continuidad de su hypervisor (vsphere) basado en ESXi en detrimento de su versión mas tradicional e implantada conocida como ESX, fundamentalmente por cuestiones de seguridad.

El impacto fundamental se debe a la perdida de la interfaz de comandos propia de cualquier distribucion Linux denominada Service Console existente en todas las versiones de ESX hasta la v4.1. En su lugar para poder gestionar ESXi, aparecen diferentes alternativas listadas a continuación y en los pantallazos adjuntos igualmente:

1.- vCLI
2.- vPowerCLI
3.- vMA (vSphere Management Assistant)

Al margen de todas estas nuevas herramientas (otras nos tan nuevas ;-) dependiendo de la licencia del ESXi es posible gestionarlo con vCenter al igual que el resto de hosts y clusters de o de los virtual Datacenters existentes de tipo ESX.

Del mismo modo, se posibilita la utilización de mas herramientas como vSphere Host Update como se puede apreciar en las imagenes adjuntas y VUM (vSphere Update Manager) la cual permite realizar lineas base a lo largo del tiempo en base a la actualización de los sistemas operativos de las VMs (Linux, Windows, UNIX, etc...) al igual que la de los propios hosts que actuan como hypervisores de la infraestructura virtual.

En los próximos articulos se trataran las novedades de las últimas versiones/releases del resto de productos de mercado que se incorporan en la temática de este blog dentro del área de la Virtualizacion de Servidores como son pueden ser Citrix XenServer y RHEV (Red Hat Enterprise Virtualization) fundamentalmente.

Convergencia de ALMACENAMIENTO y VIRTUALIZACION !!! - parte I

2010-11-09T12:13:00.029+01:00

Es conocido que la gran mayoria de las organizaciones IT ya han virtualizado en mayor o menor medidad sus servidores o están en proceso de virtualización de sus CPDs (...y los que no, se lo están planteando seriamente por todas aquellas ventajas competitivas que supone) ya sea en el caso de arquitecturas de procesador cerradas (sparc, itanium, power, etc.) o en el caso de procesadores de consumo (x86 y/o x64).

Si bien es cierto que la consolidación de servidores supone unicamente un paso previo a la virtualización completa del CPD, el siguiente escalon lo representa el hecho (en algunas organizaciones IT comienza a ser una realidad... aunque es pronto para ello) de ser capaces de orientar las operaciones IT en servicios gestionados como una nube privada y en el futuro porque no como una nube hibrida (Cloud Computing).

En esta linea de trabajo, la convergencia en la gestión unificada de las infraestructuras de almacenamiento y virtualización (de servidores y/o escritorios) de forma centralizada representa mas que un avance en el camino de la automatización del ciclo de vida de las maquinas virtuales y su operativa diaria. Este post trata de exponer como es posible este cambio tecnologico y mas aun organizativo con las cabinas de disco multiprotocolo y dispositivos NAS de NetApp en el caso concreto de DataONTAP como se puede apreciar en los pantallazos adjuntos tanto con Datastores iSCSI como NFS.

Al igual que ocurria con OpenStorage de Sun Microsystems, es relevante tener en cuenta que es posible realizar la gestión del almacenamiento de la infraestrucuta virtual (particularmente con vsphere [tanto ESX como ESXi] de VMware) con las mas que necesarias funcionalidades de "Thin Provisioning" y "Deduplicación" contando con las ventajas de las opciones multiprotocolo en lo referente al almacenamiento: FC, iSCSI, NFS, CIFS y FCoE (he hechado en falta Infiniband).

Como se puede apreciar la integración de las cabinas y/o dispositivos de NetApp en vCenter es lo que permite este cambio siendo en todo momento compatible con las diferentes herramientas de administración de la citada plataforma de almacenamiento (FilerView, System Manager y CLI).

Sin embargo la integración permite igualmente aprovechar la capacidad de tercera copia (tanto snapshots como clones) de los FlexVolumes lo que posibilita la gestión de la copia de seguridad de las VMs de forma independiente y completamente integrada en la infraestructura de almacenamiento de la cual posteriormeente seria posible realizar backup a cinta con destino VTLs o librerias fisicas si es necesario ir mas allá de la recuperación y dar cabida a los planes de respaldo y continuidad de negocio de la organización.

En el caso concreto del almacenamiento EMC asignado (directamente a los hypervisores ESX/ESXi) mediante el equipamiento NAS Celerra como frontend y como backend el equipamiento de tipo cabina de discos SAN Clariion, es de destacar que con las ultimas versiones del operativo DART del Celerra es posible realizar Thin Provisioning y Deduplicacion como se puede apreciar en la imagen adjunta.

Sin embargo la integracion de los equipos de almacenamiento de EMC con la tecnologia de virtualizacion de servidores de VMWare es posible no solo con los equipos citados (NAS Celerra y cabinas SAN Clariion) sino ademas con el equipamiento de tipo cabina de discos SAN Symmetrix (tanto los antiguos DMXs como los novedosos vMAX) apreciable igualmente en los pantallazos adjuntos.

Como apunte final de dicho articulo, destacer la existencia del software multipath PowerPath compatible con cualquier sistema de almacenamiento, el cual a diferencia del software multipath propio de VMWare (vsphere) citado anteriormente en este blog; soporta configuracion multipath en modo Round Robin pero de forma concurrente.

En posteriores articulos de este blog se tratará dicha integración en el caso particular de otros productos de virtualizacion de servidores como pueden ser Citrix XenServer cuya integración de la tecnologia de NetApp con su consola de gestión XenCenter es también posible aunque en menor medida que la indicada anteriormente. En el caso ultimo de RHEV practicamente no se aprecia dicha integración ni en el caso de la tecnologia de almacenamiento de EMC ni de NetApp, seguramente esto suponga un reto mas que importante a desarrollar en futuras releases y versiones de dicho producto.

Nueva gestión del Almacenamiento en ORACLE !

2010-07-31T16:48:00.016+02:00

En este post me gustaria tratar el cambio sustancial que supone no solo desde el punto de vista tecnologico la gestión del almacenamiento de las diferentes instancias de una BBDD Oracle directamente por el propio software de Oracle (al margen del sistema operativo) sino por este mismo motivo el cambio organizativo que representa en las operaciones y servicios IT de cualquier organización al igual que ya lo esta suponiendo la Virtualización de Servidores y la Virtualización de Escritorios (VDI).

En concreto el articulo se centra en la versión Oracle11gR1 bajo una maquina en este caso virtual que corre OEL: Oracle Enterprise Linux 5.5 (aunque por este motivo deberia funcionar sin problemas en distribuciones similares como RHEL 5.5, CentOS 5.5 e incluso UNIX como Solaris 10, aunque quedaria pendiente su posible integración con ZFS).

Para esta prueba piloto a nivel funcional se han escogido diferentes escenarios:

1.- Discos asignados directamente a la maquina virtual y posteriormente ofrecidos de forma completa a ASM (Automatic Storage Management) como gestor de almacenamiento de todas las instancias de la BBDD que correran en dicha instalacion

2.- Discos asignados directamente a la maquina virtual, se ha realizado un RAID por software (en particular RAID 1: Mirror) y el dispositivo de bloques resultante si se ha ofrecido de forma completa a ASM

3.- Discos asignados directamente a la maquina virtual, se ha realizado un VOLUMEN DINAMICO por software (en particular con LVM2) y el dispositivo de bloques resultante si se ha ofrecido de forma completa a ASM

4.- Discos asignados directamente a la maquina virtual mediante una SAN iSCSI, los discos asignados mediante el iSCSI initiator se han ofrecido de forma completa a ASM

En cualquiera de los 4 casos anteriormente citados, el resultado ha sido satisfactorio tanto en cuanto al almacenamiento de los datos estructurados de cada una de las instancias de BBDD como el del almacenamiento de los archives de las que tenian dicha funcionalidad de registro activada para mejorar su copia de seguridad, como se puede apreciar en las imagenes adjuntas.

El hecho de funcionar 100% en una SAN iSCSI, hace preveer el mismo resultado satisfactorio en una SAN Fibre Channel tanto con singlepath como con multipath. En ambos casos seria necesario evaluar importantes funcionalidades de cualquier cabina de discos actual como son el "Thin Provisioning" y "Deduplicación".

Por otro lado en la versión Oracle11gR2 se ha incorporado el hecho por el cual ASM es capaz de gestionar no unicamente el almacenamiento de los datos estructurados y archives de las diferentes instancias de una instalación, sino igualmente cualquiera de los sistemas de ficheros con datos no estructurados del sistema operativo (sorprendentemente sin recurrir al mismo) al igual que la incorporación de ACFS (ASM Cluster File System) como sistema de ficheros global en instalaciones de tipo RAC como parte de un nuevo producto y nuevo licenciamiento como es Grid Infraestructure.

Alta Disponibilidad y Balanceo de Carga en acceso a disco con VIRTUALIZACION

2010-06-20T19:33:00.036+02:00

El objetivo de este articulo es dar a conocer las diferentes opciones de Alta Disponibilidad y Balanceo de Carga en cuanto a la gestión del acceso al Almacenamiento (ya sean configuraciones singlepath o multipath) que se pueden realizar por parte de los 3 hypervisores comentados anteriormente en este blog (vSphere, XenServer y RHEV) utilizando para ello OpenStorage como cabina de discos.

Antes de nada es importante destacar que en el caso de las redes SAN de tipo FibreChannel (FCP) es habitual que los frontend de los Storage Processors de las cabinas de almacenamiento de proposito general soporten de serie dichas opciones de configuracion. Sin embargo en las cabinas de almacenamiento multiprotocolo y/o dispositivos NAS en el caso concreto de las redes SAN de tipo iSCSI es necesario para poder habilitar el acceso a disco mediante multipath que soporten el estandard ALUA (Asymmetric Logical Unit Access).

Concretamente vSphere (tanto vía CLI como a través de su conocida GUI vCenter) soporta de serie configurar estos tres metodos de acceso a disco de tipo multipath: Fixed, Most Recently Used y Round Robin, tal y como se puede apreciar facilmente en los pantallazos adjuntos a dicho post.

En particular XenServer soporta igualmente de serie acceso a disco mediante configuración multipath, sin embargo sus opciones de configuración vía CLI y mucho mas a través de su GUI XenCenter resultan bastante mas limitadas en cuanto a plantear las distintas opciones que facilmente hemos revisado con vSphere. En esta linea es necesario recurrir a StorageLink el cual permite una gestión visual y mucho mas avanzada del almacenamiento.

La configuración de Cluster (local o metropolitano) de agrupaciones de varios hypervisores XenServer utilizan asimismo datastores iSCSI y/o NFS para supervisar su estado mediante heartbeat entre los nodos implicados y la capacidad de Live Migration en cuanto a sus VMs.

Finalmente, en cuanto a RHEV al tratarse en todo momento del hypervisor KVM en empotrado en un sistema RHEL las opciones de configuración via CLI son las mismas que en el caso del software multipath (soporta Round Robin) que viene de serie con esta conocida distribución y derivadas (CentOS y Fedora). Sin embargo al igual que XenServer las opciones de configuración a través de su GUI RHEV Manager adolece de las mismas limitaciones en comparación con vSphere.

Imagen diseño SAN iSCI: Angel Ferras

Datacenter Activo - Activo con VIRTUALIZACION - parte I

2010-05-23T21:47:00.013+02:00

A raiz de la realización en la oficina de una propuesta para un cliente, aprovecho este post para exponer el planteamiento de como distribuir la produccion entre dos CPDs en la modalidad Activo - Activo tras un proceso de consolidación basado en la Virtualización de Servidores.

Con cualquiera de las tres principales tecnologias identificadas en anteriores entradas de este blog, tanto en el ecosistema de VMWare vSphere, de Citrix XenServer y de RHEV es posible utilizar con los requerimientos de LAN Extendida y SAN extendida la implementación de un MetroCluster formado por los diferentes hypervisores de cada uno de los productos de mercado citados.

En el caso concreto de VMWare vSphere al margen de la utilización de las tecnologias HA, DRS, VMotion, Storage VMotion, VCB y Fault Tolerance, de forma particular es posible respaldar igualmente vCenter con un enfoque Activo - Pasivo mediante el uso de VCenter Heartbeat, lo que incluye la replicación de todos y cada uno de sus datos de forma consistente.

En el caso opuesto, basado en un enfoque Activo - Pasivo es posible agilizar todo el proceso tradicional de Contingencia mediante la utilización de Site Recovery Manager (SRM) con el propósito de automatizar la Contigencia de un CPD a otro al tratarse las VMs de ficheros. Destacar que SRM soporta este proceso tanto de forma unidireccional como bidireccional y que se apoya fuertemente el la replicación (sincrona o asincrona) propia de las cabinas de almacenamiento de proposito general.

Mejora de procesos (ITIL) en WHYFLOSS 10

2010-04-05T13:34:00.014+02:00

Dentro del marco de la celebración de la Conferencia internacional WHYFLOSS 2010 en las instalaciones de Madrid de la EOI (Escuela de Organización Industrial), tuve el placer de poder participar como ponente exponiendo un caso de exito real y facilmente reproducible en cuanto a la orientación y mejora de procesos con el objetivo de obtener la Certificación de la ISO 2000 de un importante organismo de la administracion publica local en base a una solución de integración con diferentes herramientas Open Source.

En esta ocasión no hablamos de todos aquellos aspectos relevantes que considero necesarios dar a conocer y dominar a dia de hoy en el mundo IT... tanto en el ámbito tecnologico como en el de gestión tales como son la Virtualización, el Almacenamiento, el Cloud Computing, la Seguridad y el Open Source; temás a los que suelo estar mas orientado.

Sin embargo, está en mi ánimo y asi lo espero (y deseo ;-) que la siguiente presentación pueda aportar valor en el conocimiento de esta serie de iniciativas pioneras al igual que en la propia gestión de Servicios en base a las buenas practicas de ITIL (Information Technology Infraestructure Library):

PONENCIAS:
http://www.whyfloss.com/es/conference/madrid10/speakers

Mejora De Procesos Con Open Source Itil

View more presentations from Victor M. Fernandez.

Seguridad en Redes de ALMACENAMIENTO (SAN)

2010-02-28T20:26:00.011+01:00

Tradicionalmente en el mundo de las Redes de Almacenamiento (SAN) desde el punto de vista del protocolo Fibre Channel (FCP) las medidas de seguridad podian ser:

* Físicas: caso del Mapping, es decir la relación entre las diferentes LUNs de los DiskGroup definidos en el RAID hardware de las cabinas de discos de proposito general y los puertos de fibra del Storage Procesor de las mismas.

* Lógicas: caso del Masking, es decir la relación entre los WWPNs de las HBAs de los servidores con respecto a los LUNs (previamente mapeados en el Mapping) de las cabinas de discos; como desde el lado del Switch al realizar el Zonning, es decir la relación entre los distintos puertos de fibra de las cabinas y de los servidores ó mediante la relación de los WWPNs de las HBAs de los servidores y los WWPNs de los puertos de fibra de las cabinas.

Sin embargo, actualmente se esta produciendo un importante avance en la convergencia de las Redes de Almacenamiento al mundo TCP/IP, es decir al de las Redes de Datos. Este es el caso del protocolo Fibre Channel over Ethernet (FCoE) como de iSCSI. En el primer caso (debido a que se trata en todo momento de Ethernet) el equivalente al Zonning en el lado del Switch sería realizar el establecimiento de VLANs a Nivel II (MAC), es decir similar a la segmentación física de los dominios de broadcast tal y como se realiza a nivel físico en las Redes de Datos.

En el segundo caso, iSCSI funciona igualmente bajo Ethernet con lo cual la seguridad física se implementaría del mismo modo citado anteriormente para FCoE, en el lado del Switch. La diferencia aparece en el lado de las cabinas de discos de tipo iSCSI desde el punto de vista de la seguridad lógica. Es posible definir el Masking, es decir establecer una relación entre los IQNs de los Servidores y los LUNs que sirven las cabinas de discos y por otro lado posibilita igualmente el realizar autenticación CHAP unidireccional ó bidireccional (tanto en el lado del target como en el del initiator).

En esta ultima linea, adjunto los diferentes pantallazos de la realización de dichas medidas de seguridad en una SAN de tipo iSCSI, teniendo en cuenta la cabina de discos esta basada en ZFS como gestor de discos (RAID Z con doble paridad) y de volumenes dinamicos implementando de serie importantes funcionalidades como es el caso de ILM en cuanto al reparto de las caches de lectura y escritura, deduplicación en origen, replicación asincrona y thin provisioning al margen de otras ya citadas anteriormente en este blog.

Tal y como se puede apreciar, desde el punto de vista de los servidores (los cuales tienen acceso a los diferentes LUNs que sirve la cabina de discos iSCSI, de forma selectiva) se han realizado las pruebas con los sistemas operativos mas comunes y utilizados en este momento como es el caso de MS Windows 2008 Server R2, CentOS Linux 5.4, Sun Solaris 10u8 y OSX 10.4.11.

De forma similar se podrian implantar igualmente las medidas de seguridad lógica descritas en el caso concreto de entornos basados en la Virtualización de Servidores utilizando los hypervisores mas demandados en el mercado como es el caso de VMWare vSphere (ESX v3.5/4), Citrix XenServer (v5.0/5.5) y RHEV.

Innovación en VIRTUALIZACION !

2010-01-10T22:15:00.023+01:00

Al margen de la presentación de Virtualizacion de Servidores realizada el pasado mes Octubre, en el mercado propietario del sector de la Virtualización orientada a procesadores de consumo x86 y x64, existen productos que por su evolución o por su aparición representan innovación desde el punto de vista tecnologico:

* vSphere: En la ultima versión de VMWare ESX (no ESXi) se incorporan todas las funcionalidades conocidas con anterioridad como HA, DRS, VMotion, Storage VMotion, VCB junto con la esperada Fault Tolerance. Todo ello de forma integrada en la herramienta de gestión Virtual Center sin la necesidad de instalar ningun plugin externo añadido.

Del mismo modo incluye además las nuevas funcionalidades mucho menos conocidas y experimentadas pero no por ello menos relevantes como son: Agent Preupgrade, Linked Mode, Guided Consolidation, VCenter Heartbeat, Balloon-Driver y Transparent Memory Page Sharing.

Una caracteristica critica que no podemos olvidar es la compatibilidad y soporte con respecto a SRM intimamente relaccionado con la replicación (sincrona o asincrona) de las cabinas de almacenamiento SAN (FCP, iSCSI y NFS), muy importante en cuanto a la gestión automatizada de un DRP (Disaster Recovery Plan) dentro del mas completo BCP (Business Continuty Plan).

* XenServer: En la ultima versión exiten mejoras relevantes en cuanto a la Alta Disponibilidad de las agrupaciones de los distintos hypervisores (dom0) al mismo tiempo que la conocida Live Migration de las maquinas virtuales y la integración con los usuarios del Directorio Activo, todo ello administrado a través de la herramienta de gestión XenCenter.

Por otro lado, la funcionalidad de Continuidad de Negocio desde el punto de vista tecnologico requiere la adquisición de Protection Suite. Si bien en este caso no es necesaria la replicación (sincrona o asincrona) de las cabinas de almacenamiento entre los CDPs de producción y respaldo mediante arquitectura SAN extendida, esta herramienta realiza la replicación de ambos CPDs vía Ethernet a través de arquitectura LAN extendida ó WAN (teniendo en cuenta por supuesto su ancho de banda).

* RHEV: Esta nueva suite de Virtualización de Servidores está basada en la utilización de KVM y permite el uso tanto de RHEL como de la distribución del hypervisor "bare metal" todo ello gestionado desde la RHEV Manager de forma centralizada.

Desde el punto de vista de sus ventajas o beneficios, posibilita la Alta Disponibilidad de dichos hypervisores al mismo tiempo que la funcionalidad de Live Migration de las maquinas virtuales que albergan, permitiendo establecer para su automatización umbrales en cuanto al consumo de los recursos hardware de los mismos. Al igual que los anteriores productos citados anteriormente, la integración con soluciones de almacenamiento SAN (FCP, iSCSI y NFS) es un requerimiento para este cometido.

Existen otras soluciones dentro del mercado del software privativo las cuales ya están suponiendo el desafio de nuevos "players" en esta linea de la Virtualización del Datacenter como son el HyperV de Microsoft y xVM Ops Manager de Sun Microsystems.

Analisis de Vulnerabilidades (VA) en 5 minutos

2009-12-27T12:46:00.018+01:00

Al margen de las conocidas utilidades de hardenning de sistemas UNIX/Linux como son CISscan, Titan, Jassp, Yassp, Bastille y demás citadas en la presentación de Seguridad en OpenSolaris; las cuales desde el punto de vista de auditoría permiten conocer a un nivel de test interno como de "seguro" (mejor dicho inseguro) se encuentra el sistema a bastionar... posteriormente siempre podemos recurrir al test externo con herramientas como Nmap (la version 5 es una maravilla ;-), Nemesis, AutoScan, Superscan, Zenmap, NetGrok, OpenVAS, Nessus (desde la version 3 aunque ya no goza de licencia GPL, aunque en la version 4 incorpora mejoras realmente potentes).

Todo esto enlaza directamente con las distintas etapas de un test de penetración de seguridad IT (Planificación, Reconocimiento, Descubrimiento y Ataque) el cual proporciona un buen inventario de los activos de información decubiertos de igual modo que sus vulnerabilidades en el momento de la realización de la prueba.

Una vez alcanzado esta primera fase de identificación y escaneo, posteriormente es posible centrar el tiro en un determinado servicio (como por ejemplo el servicio web: protocolo http (puerto tcp 80) y protocolo https (puerto tco 443)) a través de otras utilidades mas concretas como nikto o su version grafica Wikto y asi sucesivamente con el objetivo de identificar vulnerabilidades facilmente trasformables en amenazas debido a la existencia y ejecución de exploits que compromentan dicho activo de información.

El siguiente paso deberia ser medir el riesgo
que supondria explotar estas vulnerabilidades inherentes a los sistemas de información, convirtiendose entonces en amenazas de los mismos. El propósito es poder cuantificar la probabilidad de su ocurrencia al igual que su posible impacto. En una fase posterior finalmente deberiamos ser capaces de materializar todas las salvaguardas proactivas que lleguen a evitar en mayor o en menos medida el riesgo de exposición a esas amenazas de cada uno de los activos descubiertos, de igual modo que articular las contramedidas necesarias siempre que sea posible mitigar dicho riesgo de una forma mas reactiva.

Mas allá del ALMACENAMIENTO...

2009-11-16T15:40:00.020+01:00

A raiz de una consulta de mi amigo Máximo, aprovecho este post para exponer las alternativas en cuanto a soluciones de almacenamiento NAS (CIFS y NFS) y SAN (iSCSI) de tipo Open Source con respecto a otro otras de tipo propietario como pueden ser Dell EquaLogic y HP Lefthand.

En el mundo de las distribuciones Linux esta teniendo un gran apoyo y aceptación OpenFiler el cual incorpora entre otras ventajas la posibilidad de realizar Bonding entre sus diferentes interfaces de red.

A medio camino, es necesario nombrar la existencia de FreeNAS, el cual permite comparticion de ficheros a través de NFS y CIFS al igual que servir dispositivos de bloques via iSCSI. Sin embargo a diferencia de su equivalente anterior en el mundo Linux, la gestión del almacenamiento es posible realizarla con ZFS (con todas las ventajas que esto supone) aunque en una version anterior a la implementación de ZFS bajo las distribuciones y appliances basados en OpenSolaris incluido Solaris.

En el ámbito de las distribuciones OpenSolaris, es de destacar las ventajas que incorporan tanto Open Storage (Sun Microsystems) y NexentaStor (Nexenta Systems) al incluir igualmente la funcionalidad de Link Aggregation (Nivel II) al mismo tiempo que IPMP (Nivel III) entre sus diferentes interfaces de red.

Al implementar ZFS como motor de almacenamiento interno (sistemas de ficheros al igual que gestor de discos), resulta realmente interesante al margen de todas las opciones de snapshots, clones (tercera copia), replicación asincrona, "thin provisioning" y deduplicación a nivel de bloque como funcionalidades de serie, la capacidad de poder realizar la distribución de las distintas caches de lectura y escritura en diferentes discos (SATA, SAS, SSD e incluso memorias Flash) como se puede apreciar facilmente en siguiente ilustración:

Virtualización de Servidores en MadridOnRails 09

2009-10-12T12:42:00.012+02:00

El pasado miercoles 21 de Octubre celebraremos en MadridOnRails el evento tecnológico "Virtualización y Cloud Computing".

En esta ocasión asistí como ponente de la parte de "Virtualización de Servidores" con enfoque Open Source al mismo tiempo que mi colega Diego Parrilla hizo lo propio en el parte de "Cloud Computing".

PONENCIAS
http://eventos.madridonrails.com/eventos-divulgativos/23-qvirtualizacion-y-cloud-computingq.html

Virtualizacion De Servidores

View more documents from vfernandezg.

MadridOnRails - De la Virtualización al Cloud Computing: Cómo implantar una Nube Privada con código abierto

View more presentations from abiquodocs.

Gestión Documental (ECM) en 5 minutos

2009-10-12T11:22:00.014+02:00

Dentro de la estrategia de ahorro de coste directo energético junto con la nueva estrategia de sostenibilidad con respecto al medio ambiente, en lo que se ha venido a denominar "Green IT", existe un posicionamiento cada día mas evidente de las soluciones de "Gestión Documental".

En este sentido, desde el enfoque Open Source el producto Alfresco ofrece funcionalidades realmente interesantes al igual que una arquitectura web distribuida que permite en todo momento Balanceo de Carga al mismo tiempo que Alta Disponibilidad.

Si nos centramos en las funcionalidades( tal y como me trasmitio mi buen amigo y excelente profesional Toni) al margen de la sencilla interfaz web de uso y administración... permite habilitar el acceso al contenido personalizado de cada usuario a traves de protocolos comunes de accceso como son WEBDAV, CIFS, NFS, SHAREPOINT, IMAP, SMTP... posibilitando la necesidad (o no) de establecer flujos de aprobacíon/desaprobación del mismo (más conocido como WorkFlow).

Y por ultimo desde el punto de vista más técnico, es compatible 100% con cualquier distribución Linux y OpenSolaris (incluido Sun Solaris 10 update 8). En concreto las pruebas funcionales se han realizado con clasicos productos de infraestructuras: GlassFish como servidor de aplicaciones, Apache como servidor web (incluido protocolo AJP), MySQL como base de datos relaccional de configuración y OpenDS como repositorio de usuarios tipo LDAP. Finalmente solo destacar que en cuanto al almacenamiento de los contenidos del gestor documental es mas que recomendable la utilizacion de protocolos de bloques SAN (iSCSI, FC, FCoE...) en lugar de protocolos de ficheros NAS (NFS, CIFS...) en cada uno de los diferentes nodos donde se despliega Alfresco a ser posible con acceso concurrente al mismo a través de sistemas de ficheros globales como QFS, GFS...

Cloud Computing en Sun Open Communities Forum 09

2009-05-17T09:32:00.024+02:00

Los pasados jueves y viernes 18 y 19 de junio respectivamente se celebraron en la Escuela Politécnica Superior de la Universidad San Pablo CEU (Boadilla del Monte, Madrid) el evento "Sun Open Communities Forum". De asistencia gratuita, el Forum estuvo especialmente dirigido a desarrolladores y tecnólogos tanto del ámbito empresarial como universitario.

En concreto en esta edición realizé una ponencia con un caso práctico acerca de todos los conceptos junto con el nuevo enfoque que aporta a los servicios IT, el denominado CLOUD COMPUTING (Computación en la nube) tanto en los entornos de desarrollo, preproducción actuales como en los futuros ambientes de producción.

-> VIDEO DE LA CONFERENCIA <-
http://sunopencommunitiesforum.es/ponencias.html

PONENCIAS
http://sunopencommunitiesforum.es/agenda.html

Cloud Computing

View more Microsoft Word documents from vfernandezg.

Virtualizacion y Cloud Computing en WhyFLOSS 09

2009-05-17T09:18:00.018+02:00

Conferencias gratuitas de tecnologías abiertas de IT en Madrid

El pasado jueves 21 mes de Mayo de este año se celebró la 7ta edición de la WhyFLOSS Conference, con entrada LIBRE y GRATUITA y con CERTIFICADOS DE ASISTENCIA y PONENCIA. Un evento internacional organizado por Neurowork que se realiza en España y Argentina y que esta vez se realizará por segunda vez en la ciudad de Madrid.

En esta conferencia en particular participé como moderador del Eje de Tendencias Virtualización y Cloud Computing.

-> VIDEO DE LA CONFERENCIA <-
http://www.whyfloss.com/es/conference/madrid09/video/167

PRESENTACIONES
http://www.whyfloss.com/es/conference/madrid09/getpdf/167

http://www.whyfloss.com/es/conference/madrid09/getpdf/184

Apertura WHYFLOSS 09 Madrid

View more Microsoft Word documents from guest66bbc80.

PONENCIAS
http://www.whyfloss.com/es/conference/madrid09/speakers

Seguridad Web Open Source en ISSA 09

2009-05-15T11:52:00.014+02:00

En el marco de la asocación ISSA España, aprovecho este post para publicar la presentación planificada para realizarse el pasado 8 de Mayo de este 2009 en la primera ronda de conferencias de dicha asociación internacional en las instalaciones que nos brindó el Instituto de Física Aplicada del CSIC de Madrid.

Finalmente y por falta de quorum la sesión se va a trasladar al proximo mes de Septiembre.
Os mantendre informados !

PONENCIAS
http://www.issa-spain.org/?p=65

Seguridad Entornos Web Open Source

View more presentations from vfernandezg.

Apostando por el CLOUD COMPUTING !

2009-03-22T19:13:00.017+01:00

Hace tiempo vi en el blog de mi buen amigo Toni el video que ha publicado Citrix acerca del novedoso y futurible concepto de Infraestructuras basado en el Cloud Computing. En dicho post se explica de forma muy sencilla la idea de trasfondo de la computación bajo demanda, al mismo tiempo que se exponen sus diferencias con el más actual concepto de tipo SaaS (Software as a Service).

En este caso aprovecho la ocasión para demostrar la utilización de los EC2 (Elastic Computing Cloud) de Amazon. En concreto existe un importante abánico de diferentes posibilidades, sin embargo lo mas destacado reside en la capacidad de uso de cualquiera de su listado de maquinas virtuales publicadas bajo demanda, al igual que el uso de almacenamiento remoto tambien bajo demanda.

Adjunto imagenes que confirman la compatibilidad con las distintas herramientas de acceso como son ElasticFox, S3Fox e incluso a través de los protocolos VNC y SSH.

Mas allá de la VIRTUALIZACIÓN...

2009-02-25T22:23:00.019+01:00

Aprovecho este post para comentar un buen abanico de soluciones Open Source en el ámbito de la virtualización especialmente en el caso concreto de Linux y de OpenSolaris.

Desde el punto de vista de la virtualización, tanto la basada en el sencillo concepto de contenedores por instancia única de anfitrión, como la centrada en la existencia de la figura clave de un hypervisor asistido por software o por hardware. Esta última mucho mas dependiente de las extensiones de los procesadores de consumo x86 y x64 (Intel y AMD), es necesario destacar la cercania al concepto de Cloud Computing existente en la solución bare metal de Proxmox (KVM y OpenVZ). Aunque no podemos dejar de nombrar otras no siendo bare metal pero igualmente prácticas, como pueden ser Enomaly (KVM y Xen), HyperVM (Xen y OpenVZ) y mucho mas de lejos Vtonf (OpenVZ).

De igual modo Citrix Systems ha liberado recientemente su versión de Xen Server, al mismo tiempo compañias como Red Hat y Sun Microsystems ya han publicado su común interés en este tipo de Soluciones.

Servidor de Aplicaciones (J2EE) en 5 minutos

2009-01-13T16:11:00.016+01:00

Aprovecho este post para comentar las ventajas de la utilización de tres potentes productos como son Tomcat, GlassFish y JBoss en cuanto a su capacidad para servir aplicaciones J2EE dentro de una Arquitectura Web multicapa.

Dichos productos Open Source, soportan el protocolo de tipo Tcp denominado AJP, el cual permite el uso de la infraestructura de Apache como frontal Web de los mismos.
Esto es relevante ya que su módulo mod_jk a diferencia del mod_proxy, permite la utilización de métodos de Balanceo de Carga entre los Clusters de Alta Disponibilidad agrupados entre los propios servidores de aplicaciones implementados con cada uno de estos productos.

Adjunto imagenes que confirman la compatibilidad y soporte de estos productos con cualquier distribución tanto del mundo Linux como OpenSolaris.

Todo ello sin olvidar como Bakcend los repositorios de información como son las Bases de Datos y los directorios de tipo LDAP.

Single Sing On (SSO) en 5 minutos

2009-01-09T13:57:00.006+01:00

Continuando con los procedimientos de protección de activos de información, iniciado en el post anterior no podia dejar pasar los mecanismos de salvaguarda de lo que comunmente se conoce como una Arquitectura Web (monocapa, bicapa o tricapa).

Adjunto imagenes de como desplegar dicha solución con la herramienta OpenSSO de forma centralizada (toda la configuración reside en el Servidor) o distribuida (clásico modelo Servidor / Agente) utilizando como repositorio OpenDS. En este caso concreto se protege la infraestructura implementada con SJWS restringiendo el control de acceso, pero es completamente funcional con otros productos como Apache e incluso servidores J2EE.

Autoridad Certificadora (CA) en 5 minutos

2008-12-30T14:36:00.013+01:00

Dentro de la estrategia de implantación de un SGSI por proceso de Negocio, (alineada con la Politica de Seguridad de una Compañia) supongamos que esta ultima ha optado por mitigar los riesgos asociados a las vulnerabilidades de sus activos de información (lo que supone en caso contario supondría una amenzaza), mediante la implantacion de las salvaguardas correspondientes.

En tal caso no podemos dejar de hablar de alguna solución de tipo CA. En concreto la herramienta GnoMint cubre perfectamente esta funcionalidad a través de una sencilla e intuitiva GUI a diferencia de utilidades similares como OpenSSL y PKTool. Por supuesto sin llegar a cubrir todas las ventajas que incorpora una PKI.

Adjunto imagenes ilustrativas de como firmar las peticiones de certificados de productos clácicos de Infraestructura IT como son Apache, OpenLDAP, OpenDS, FedoraDS, SJWS y DSEE con el certificado de la entidad certificadora (raiz o subordinada), al igual que el video ilustrativo acerca de como realizarlo con OpenVPN.

Innovación en ALMACENAMIENTO !

2008-12-04T15:43:00.024+01:00

Aprovecho este post para comentaros que hace ya algun tiempo Nexenta Systems sacó al mercado su pionero producto de Almacenamiento más conocido como NexentaStor el cual actualmente cubre todas las necesidades de un NAS (tanto acceso a ficheros a traves de CIFS y NFS, como acceso a dispositivos de bloques via iSCSI...). Lo novedoso del mismo reside en que la gestión local y remota de los discos se realiza internamente con el popular sistema de ficheros ZFS con todas las ventajas que aporta el uso y distribucion de las caches y registros de transacciones mediante ARC, L2ARC y ZIL sin olvidar la replicación, todo ello desarrollado bajo el proyecto OpenSolaris.

Posteriormente y a su vez de forma reciente Sun Microsystems acaba de sacar su alternativa más conocida como OpenStorage con las mismas funcionalidades y algo mas de integración con DTRACE lo que se trasmite graficas de rendimiento con un apreciable nivel de detalle.

Open Source World Conference 09 (OSWC 09)

2008-11-05T11:35:00.022+01:00

Aprovecho este articulo para comentaros la necesaria participacion que realizó OpenSolaris Hispano en este importante y relevante evento internacional, el cual se celebró los pasados 20, 21 y 22 de Noviembre bajo el paraguas de la ciudad de Málaga con este interesante a la vez que completo programa.

De forma similar a anteriores ocasiones, la presentación realizada para dicha ponencia ya esta disponible, tanto en es este blog como en la seccion del portal de la Comunidad OpenSolaris Hispano.

-> VIDEO DE LA CONFERENCIA <-

Presentacion OpenSolaris - Demo OpenBravo ERP

Presentacion Demo Open Solaris

View more documents from guest926912.

OpenSolaris Day 08

2008-05-29T16:07:00.023+02:00

Los pasados días 26 y 27 de Junio celebramos en Madrid (UCM: Facultad de Matemáticas) este destacado evento anual: "OpenSolaris Day".

Al igual que en ediciones anteriores la asistencia fue gratuita y libre para todos los asistentes.

Las fotos mas relevantes de este importante evento Open Source las podeis ver aquí. Ademas existe un resumen del evento en la edicion digital de Gaceta Tecnologica.

Las presentaciones de las ponencias y talleres ya estan disponibles, tanto en es este blog como en la seccion del portal de la Comunidad OpenSolaris Hispano.

SugarCRM en OpenSolaris (CRM)

| View | Upload your own

Monitorizacion en OpenSolaris (ITIL v2/3)

| View | Upload your own

Jornadas Técnicas UPM 08

2008-05-20T18:54:00.014+02:00

Dentro del marco de actividades de la Comunidad OpenSolaris Hispano, aprovecho este post para trasladaros el evento del próximo Viernes 23/5/2008 de 16:00 a 18:00 que se celebrará en la Facultad de Informática de la UPM (Universidad Politécnica de Madrid). En particular la ponencia consiste concretamente en "Novedades: Virtualización / Almacenamiento en OpenSolaris".

Como en anteriores ocasiones la asistencia al mismo es libre y gratuita.
La presentación ya está disponible tanto en este blog como la sección de Presentaciones y Talleres del portal de la Comunidad OpenSolaris Hispano.

Virtualización y Almacenamiento en OpenSolaris (ITIL v2/3)

| View | Upload your own

Sun Microsystems Technical Fridays 08

2008-04-14T08:49:00.010+02:00

Como parte de las actividades e iniciativas de OpenSolaris Hispano, el próximo día 25 de este mes de Abril del 2008, se celebrará la 3ra edición de las jornadas denominadas Viernes Técnicos aqui en Madrid. La entrada es gratuita y el registro es necesario realizarse via Web, aqui.

Esta edición consistirá en un monográfico detallado en base a las diferentes tecnologías de Almacenamiento presentes en las multiples distribuciones actuales englobadas dentro el proyecto internacional OpenSolaris.

La presentacion ya está disponible tanto en este blog como la sección de Presentaciones y Talleres del portal de la Comunidad OpenSolaris Hispano.

Almacenamiento en OpenSolaris (ITIL v2/3)

| View | Upload your own

Conferencia WHYFLOSS 2008

2008-04-09T17:27:00.026+02:00

En los próximos días 8 y 9 del mes de Mayo de este año 2008, se celebrará la 4ta edición de la WhyFLOSS Conference aqui en Madrid. La entrada es gratuita y el registro puede realizarse via Web, aqui.

En este evento profesionales de conocias compañías del sector junto a universidades como la UPM y la URJC, al igual que comunidades de proyectos como LibreSoft, OpenSolaris Hispano y FFII estarán colaborando en la IV edición.

La presentacion ya está disponible tanto en este blog como la sección de Presentaciones y Talleres del portal de la Comunidad OpenSolaris Hispano.

-> VIDEO DE LA CONFERENCIA <-

Seguridad en OpenSolaris (SGSI, ISO 27000)

| View | Upload your own

OpenSolaris en Linux Magazine II

2008-03-19T12:17:00.008+01:00

Aprovecho este post para anunciaros que ya está disponible el artículo de OpenSolaris del mes de marzo en la edición española de Linux Magazine.

A diferencia del anterior más orientado en cuanto a una introducción a OpenSolaris e instalación del mismo, esta nueva publicación trata en profundidad las diferencias existentes en el arranque que se produce en máquinas con arquitecturas de procesador SPARC y de tipo x86.

Arranque de OpenSolaris (SPARC y x86)

Jornadas Técnicas UC3M 2008

2008-03-14T14:43:00.010+01:00

Como miembro activo de la Comunidad Hispana OpenSolaris, aprovecho este post para anunciar las presentaciones que realizé el lunes 10/3/2008 y miércoles 12/3/2008 en el marco de las jornadas GUL-UC3M 2008, que tuvo lugar en Madrid.

Ambas presentaciones ya están disponibles tanto en este blog como la sección de Orange Books del portal de la Comunidad Hispana.

OpenSolaris y Comunidad

Virtualización en OpenSolaris

| View | Upload your own

OpenSolaris en Linux Magazine I

2008-01-19T12:35:00.010+01:00

Aprovecho este post para anunciaros que a partir del mes de Enero de este año 2008, esta previsto incluir una serie de artículos acerca de OpenSolaris en la edición española de Linux Magazine.

La idea consiste en una serie completa, que recoja desde la Instalación y Configuración inicial hasta los aspectos mas relevantes de todas las nuevas tecnologías presentes en OpenSolaris (SMF, ZFS, DTRACE, Zonas/Contenedores, IPFilter...) y que ya están siendo portadas a otros sistemas operativos de tipo Unix como OSX, FreeBSD y Linux.

Instalación de OpenSolaris (x86)

Ext2 y NTFS en OpenSolaris

2007-12-22T10:55:00.000+01:00

En este breve artículo vamos a comentar como ser capaz de acceder a los datos de una determinada partición Ext2 o NTFS desde nuestro sistema OpenSolaris.

Lo primero que tenemos que hacer es descargarnos estos dos paquetes: FSWpart y FSWfsmisc de la distribucion Belenix.

Posteriormente los instalamos:

# gunzip -c FSWpart.tar.gz | tar xvf -

# pkgadd -d . FSWpart

# gunzip -c FSWfsmisc.tar.gz | tar xvf -

# pkgadd -d . FSWfsmisc

Y ya podemos montar de manual las particiones de estos dos sistemas de ficheros:

# mount -F ext2fs /dev/dsk/c0d0s4 /mnt

# mount -F ntfs /dev/dsk/c0d0s5 /mnt

O si necesitamos que se monten automatiamente en el arranque del sistema, indicarlo con una entrada para cada una de ellas en la tabla /etc/vfstab.

Como ayuda para identificar las particiones de un disco recnocido, no es necesario utilizar el comando format e ir navegando por sus distintas opciones... es más sencilla esta otra opción:

# /usr/bin/prtpart /dev/rdsk/c0d0 -ldevs

Congreso Hispalinux 2007

2007-12-16T22:07:00.004+01:00

Como miembro activo de la Comunidad Hispana OpenSolaris, aprovecho este post para anunciar la presentación que realizé el pasado sabado 15/12/2007 en la décima edición del Congreso Hispalinux 2007, el cual tuvo lugar en Caceres (Extremadura).

La presentación ya esta disponible tanto en este blog como la sección de Orange Books del portal de la Comunidad Hispana.

OpenSolaris - Almacenamiento con ZFS

filtros TCP_WRAPPER

2007-12-10T18:05:00.004+01:00

Una de las nuevas funcionalidades de seguridad que incorpra Solaris 10 / OpenSolaris reside que la mayoria de servicios de red o de acceso al sistema ya estan integrados con TCP_WRAPPER.

En este articulo vamos a ver como permitir/denegar el acceso al puerto TCP 1111, el cual es habilitado por el proceso rpcbind (utilizado para clientes NFS, NIS...). Es decir podemos limitar los hosts que envian peticiones de tipo RPC a nuestro sistema.

Dentro de SMF, entramos en este servicio de red, asi:

# svccfg
svc:> select network/rpc/bind
svc:/network/rpc/bind> listprop
config application
config/allow_indirect boolean true
config/verbose_logging boolean true
config/enable_tcpwrappers boolean true
fs dependency
fs/entities fmri svc:/system/filesystem/minimal
fs/grouping astring require_all
fs/restart_on astring none
fs/type astring service
identity dependency
identity/entities fmri svc:/system/identity:node
identity/grouping astring require_all
identity/restart_on astring refresh
identity/type astring service
sysidtool dependency
sysidtool/entities fmri svc:/system/sysidtool:net
sysidtool/grouping astring require_all
sysidtool/restart_on astring none
sysidtool/type astring service
routing dependency
routing/entities fmri svc:/network/initial:default
routing/grouping astring optional_all
routing/restart_on astring none
routing/type astring service
general framework
general/entity_stability astring Unstable
general/single_instance boolean true
start method
start/exec astring "/lib/svc/method/rpc-bind %m"
start/group astring root
start/limit_privileges astring :default
start/privileges astring basic,file_chown,file_chown_self,file_owner,net_privaddr,proc_setid,sys_nfs
start/project astring :default
start/resource_pool astring :default
start/supp_groups astring :default
start/timeout_seconds count 60
start/type astring method
start/use_profile boolean false
start/user astring root
start/working_directory astring :default
stop method
stop/exec astring "/lib/svc/method/rpc-bind %m %{restarter/contract}"
stop/group astring root
stop/limit_privileges astring :default
stop/privileges astring basic,proc_owner
stop/project astring :default
stop/resource_pool astring :default
stop/supp_groups astring :default
stop/timeout_seconds count 60
stop/type astring method
stop/use_profile boolean false
stop/user astring root
stop/working_directory astring :default
tm_common_name template
tm_common_name/C ustring "RPC bindings"
tm_man_rpcbind template
tm_man_rpcbind/manpath astring /usr/share/man
tm_man_rpcbind/section astring 1M
tm_man_rpcbind/title astring rpcbind

Habilitamos el filtrado:

svc:/network/rpc/bind> setprop config/enable_tcpwrappers=true

Finalizamos la edicion de este servicio y lo reiniciamos:

svc:/network/rpc/bind> end

# svcadm restart rpc/bind

Justo en este momento, ya estamos en condiciones de configurar el acceso. Denegamos todo y unicamente permitimos el acceso a través de la interface de loopback.

# cat /etc/hosts.deny
ALL: ALL

# cat /etc/hosts.allow
rpcbind: 127.0.0.1

Y comprobamos que dicho filtrado es correcto:

# uname -a
SunOS opensolaris 5.10 Generic_120012-14 i86pc i386 i86pc

# telnet opensolaris 1111
Trying 10.73.130.251…
telnet: connect to address 192.168.1.3: Connection refused

Fácil, no?

SVM fácil y rápido

2007-12-03T11:32:00.001+01:00

En este artículo vamos a ver de forma sencilla y cómoda como actualizar nuestro Solaris 10 / OpenSolaris corriendo el mínimo riesgo posible.

Partimos de una situación inicial en la cual tenemos una configuración básica de Solaris Volume Manager para el filesystem / y el área de swap.

# uname -a
SunOS opensolaris 5.10 Generic_120012-14 i86pc i386 i86pc

# df -h| grep dsk
/dev/md/dsk/d0 5,4G 4,2G 1,2G 79% /

# swap -l
swapfile dev swaplo bloques libre
/dev/md/dsk/d10 85,10 8 1048568 1048568

La configuración del RAID 1 (mirror) en cada uno de los filesystem implicados es esta:

# metastat -p
d10 -m d11 d12 1
d11 1 1 c0d0s1
d12 1 1 c0d1s1
d0 -m d1 d2 1
d1 1 1 c0d0s0
d2 1 1 c0d1s0

Luego en ese momento ejecutamos el script unmirror.sh, asi:

# ./unmirror.sh
bash-3.00# ./unmirror.sh
d10: subduplicación d12 quitada
d0: subduplicación d2 quitada
Press any key to reboot system. After rebooting, check //log/unmirror_cont.log for result.
y

El sistema se reiniciará y arrancará sin ningun tipo de RAID 1, luego unicamente los cambios en la actualización del mismo o su parcheado se registraran en los subdiscos activos en ese momento.

# metastat -p
d10 -m d11 1
d11 1 1 c0d0s1
d0 -m d1 1
d1 1 1 c0d0s0
d12 1 1 c0d1s1
d2 1 1 c0d1s0

Por lo tanto, siempre podremos arrancar nuestro sistema con los subdiscos que no estan activos y que no se ven afectados por este proceso de actualización.

* * * ACTUALIZAMOS * * *

Una vez que el sistema ya actualizado arranca perfectamente, simplemente con el siguiente script (generado por el anterior "unmirror.sh"), volvemos a crear la tolerancia a fallos a nivel del mirror activa en el próximo arranque, asi:

# ./remirror

metainit: opensolaris: d10: unidad ya configurada

metainit: opensolaris: d0: unidad ya configurada

The output of metastat -p is:
d10 -m d11 d12 1
d11 1 1 c0d0s1
d12 1 1 c0d1s1
d0 -m d1 d2 1
d1 1 1 c0d0s0
d2 1 1 c0d1s0
Press any key to reboot system to finish mirroring.

FTP Anónimo

2007-11-26T12:39:00.001+01:00

Tanto en Solaris 10, como en OpenSolaris hay algunos cambios en cuanto a la generación de un servidor FTP acotado para el acceso permitido de cualquier usuario sin cuenta en nuestro sistema.

Por defecto el demonio que nos permite ejecutar el servidor FTP (WU-FTP) estará activo y controlado por SMF.

# svcs -a | grep ftp
online 15:28:42 svc:/network/ftp:default

Lo primero que vamos a realizar es crear un $HOME para el usuario ftp, asi:

# mkdir -p /export/ftp/{pub,bin,dev,etc,usr/lib}

Una vez realizado, copiamos el binario del comando "ls" y le asignamos los permisos necesarios:

# cp /usr/bin/ls /export/ftp/bin
# chmod 111 /export/ftp/bin/ls

Solo nos queda copiar a ese path las librerias necesarios para le ejecución de dicho binario:

# cp /usr/lib/ld.so* /export/ftp/usr/lib
# cp /usr/lib/libc.so.1 /usr/lib/libdl.so.1 /export/ftp/usr/lib
# cp /usr/lib/libintl.so.1 usr/lib/libw.so.1 /export/ftp/usr/lib
# cp /usr/lib/nss*.so.1 /export/ftp/usr/lib
# cp /usr/lib/libnsl.so.1 /export/ftp/usr/lib
# cp /usr/lib/straddr.so /export/ftp/usr/lib

Y los correspondientes ficheros de configuración:

# cp /etc/passwd /etc/group /etc/netconfig /export/ftp/etc
# cp /etc/nsswitch.conf /export/ftp/etc

Con su asignación correcta de permisos:

# chmod 555 /export/ftp/usr/lib/*
# chmod 444 /export/ftp/etc/*
# chmod 555 /export/ftp/usr/lib
# chmod 555 /export/ftp/usr
# chmod 555 /export/ftp/bin
# chmod 555 /export/ftp/dev
# chmod 555 /export/ftp/etc
# chmod 755 /export/ftp/pub
# chmod 555 /export/ftp

Es en este momento cuando creamos el usuario ftp con acceso anónimo al sistema por este procolo TCP.

# vi /etc/passwd
ftp:x:30000:30000:Anonymous FTP:/export/ftp:/bin/false

# vi /etc/shadow
ftp:NP:6445::::

Y por ultimo securizamos todo el $HOME:

# chown -R root /export/ftp

Hemos conseguido un acceso anónimo real a nuestro servidor FTP, completamente acotado en el PATH que hemos reservado (/export/ftp) y además de forma enjaulada ya que nunca podra subir directorios por el arbol de directorios.

III Jornadas COPLA

2007-11-15T14:43:00.002+01:00

Como miembro activo de la Comunidad OpenSolaris en Castellano, aprovecho este post para anunciar la presentación que realizé el pasado viernes 23/11/2007 en la tercera edición de las jornadas COPLA de la Universidad de Alicante.

La presentación ya esta disponible tanto en este blog como la sección de Orange Books del portal de la Comunidad Hispana.

OpenSolaris - Un sistema operativo para el futuro

Zonas y Contenedores bajo ZFS

2007-11-05T21:54:00.002+01:00

Una de las ventajas de crear zonas y/o contenedores bajo el nuevo sistema de ficheros ZFS, reside que nos podemos apoyar en la creación de sanpshot y clones para mover un contenedor de un sistema real (anfitrión) a otro.

La zona global origen tiene como hostname "opensolaris" y el sistema anfitrión destino se denomina "opensolaris2".

Partimos de una zona de tipo BrandZ acotada en cuanto al consumo de memoria y swap:

# hostname
Opensolaris

# zonecfg -z zonelx info
zonename: zonelx
zonepath: /opt/zones/zonelx
brand: lx
autoboot: false
bootargs: -m verbose
pool:
limitpriv:
scheduling-class:
ip-type: shared
net:
address: 10.73.130.249/24
physical: pcn0
capped-memory:
physical: 256M
[swap: 128M]
[locked: 50M]
rctl:
name: zone.max-swap
value: (priv=privileged,limit=134217728,action=deny)
rctl:
name: zone.max-locked-memory
value: (priv=privileged,limit=52428800,action=deny)

y de los siguientes filesystems ZFS:

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
mypool 1,57G 380M 26,5K none
mypool/zonas 1,57G 380M 1,57G /opt/zones/

Lo primero que hacemos es "desenganchar" del sistema anfitrión origen, el contenedor que vamos a mover:

# zoneadm -z zonelx detach

Posteriormente realizamos un snapshot de dicho filesystem sobre el que reside el contenedor denominado zonelx.

# zfs snapshot mypool/zonas@Snap1

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
mypool 1,34G 2,94G 24,5K none
mypool/zonas 1,34G 2,94G 1,34G /opt/zones/
mypool/zonas@Snap1 0 - 1,34G -

Una vez que tenemos la imagen como resultado de la snapshot, realizamos un backup de la misma a un fichero local.

# zfs send mypool/zonas@Snap1 > /opt/zones/zonelx.Backup1 &

Y ese mismo fichero resultado del backup lo llevamos por ssh al anfitrión destino.

# scp /opt/zones/zonelx.Backup1 un38134@10.73.130.247:/export/home/un3813 &

Una vez que estamos en el sistema destino, unicamente creamos el pool ZFS deniminado "mypool" y sobre el realizamos la importación del fichero resultado del backup de la snapshot realizado en el sistema origen.

# hostname
opensolaris2

# df -h
Sistema de archivos tamaño usados aprovechar capacidad Montado en
/dev/dsk/c0d0s0 5,4G 3,8G 1,6G 71% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 811M 856K 810M 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
/usr/lib/libc/libc_hwcap1.so.1
5,4G 3,8G 1,6G 71% /lib/libc.so.1
fd 0K 0K 0K 0% /dev/fd
swap 810M 40K 810M 1% /tmp
swap 810M 28K 810M 1% /var/run
mypool 1,9G 24K 1,9G 1% /mypool

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
mypool 91K 1,94G 24,5K none

# zfs receive mypool/zonas < /export/home/un38134/zonelx.Backup1

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
mypool 1,34G 2,94G 24,5K none
mypool/zonas 1,34G 2,94G 1,34G /opt/zones/
mypool/zonas@Snap1 0 - 1,34G -

Una vez importado el sanpshot ZFS podemos crear el contenedor, asi:

# zonecfg -z zonelx
zonecfg:zfszone2> create -a /opt/zonas/zonelx
zonecfg:zfszone2> exit

Una vez creada la zona, la podemos "enganchar" en el anfitrión destino.

# zoneadm -z zonelx attach

# zoneadm list -iv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
- zonelx installed /opt/zones/zonelx lx shared

Una vez creada, la podemos arrancar y acceder a ella.

# zoneadm -z zonelx boot

# zlogin zonelx
[Conectado a la zona 'zonelx' pts/2]

Welcome to your shiny new Linux zone.

- The root password is 'root'. Please change it immediately.

- To enable networking goodness, see /etc/sysconfig/network.example.

- This message is in /etc/motd. Feel free to change it.

For anything more complicated, see:
http://opensolaris.org/os/community/brandz/

You have mail.
# uname -a
Linux zonelx 2.4.21 BrandZ fake linux i686 i686 i386 GNU/Linux

# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0C:29:2D:04:A0
inet addr:10.73.130.249 Bcast:10.73.130.255 Mask:255.255.255.0
UP BROADCAST RUNNING SLAVE MTU:1500 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING SLAVE MTU:8232 Metric:1

Luego de una forma sencilla y con muy poco tiempo de perdia de servivio hemos movido un contenedor (con toda su configuración) de un sistema anfitrión inicial a otro destino.

Screencast ZFS

2007-10-22T22:12:00.002+02:00

Aprovecho este articulo para adjuntar un par de enlaces geniales acerca de la gestión de discos que podemos realizar de forma sencilla con el nuevo sistema de ficheros del futuro: ZFS.

1.- Administración Básica ZFS. (con audio en Inglés). En este vídeo se muestra fácilmente la creación de 100 sistemas de ficheros practicamente en 5 minutos.

2.- Administración Avanzada ZFS. En este vídeo se muestra la recuperación silenciosa de sistemas de ficheros ZFS y como se pueden reparar de la corrupción de datos que ocurre en ocasiones en los volúmenes reflejados.

Espero os sirva de ayuda.

Contenedores BrandZ

2007-10-17T19:14:00.003+02:00

Tras la publicación de la nueva Release 8/07 de Solaris 10 por parte de Sun Microsystems, caben destacar entre sus nuevas funcionalidades, la posibilidad de configurar los Contenedores a través de la propia configuracion de las zonas virtuales, al igual que la asignación dedicada de los interfaces de red reales de la zona global.

La funcionalidad de asignar un interface de la zona global (anfitrión) para una zona virtual, no es compatible actualmente con las de tipo BrandZ, pero si el sistema virtualizado es Solaris 10 se puede configurar facilmente en la seccion general, asi:

# zonecfg -z zonepruebas
zonelx: No se ha configurado esa zona
Use 'create' para comenzar a configurar una zona nueva.
zonecfg:zonepruebas> create
zonecfg:zonepruebas> set zonepath=/opt/zones/zonepruebas
zonecfg:zonepruebas> set ip-type=exclusive
zonecfg:zonepruebas> add net
zonecfg:zonepruebas:net> set physical=pcn0
zonecfg:zonepruebas:net> end
zonecfg:zonepruebas> exit

Posteriormente configurariamos el interface de red pcn0 en el sistema virtualizado como si se tratase del anfitrión, e incluso podemos filtrar su tráfico con IPFilter.

# zlogin -C zonepruebas

# ifconfig pcn0 plumb

# ifconfig pcn0 inet 192.168.1.2 netmask 255.255.255.0 broadcast +

# route add default 10.73.130.1

# cat /etc/ipf/ipf.conf
### Block all inbound and outbound traffic by default
block in log on pcn0 all head 100
block out log on pcn0 all head 150

### Allow inbound SSH connections
pass in quick proto tcp from any to any port = 22 keep state group 100

### Allow my box to utilize all UDP, TCP and ICMP services
pass out quick proto tcp all flags S/SA keep state group 150
pass out quick proto udp all keep state group 150
pass out quick proto icmp all keep state group 150

# svcadm enable ipfilter

# ipf -f /etc/ipf.conf

En el siguiente ejemplo vamos a definir la configuración de una zona virtual (en la que instalaremos una imagen de CentOS 3.0) la cual vamos a acotar en cuanto a sus recursos de CPU y memoria durante su definición, asi:

# zonecfg -z zonelx
zonelx: No se ha configurado esa zona
Use 'create' para comenzar a configurar una zona nueva.
zonecfg:zonelx> create -t SUNWlx
zonecfg:zonelx> set zonepath=/opt/zones/zonelx
zonecfg:zonelx> set autoboot=true
zonecfg:zonelx> add net
zonecfg:zonelx:net> set physical=pcn1
zonecfg:zonelx:net> set address=10.73.130.249/24
zonecfg:zonelx:net> end
zonecfg:zonelx> add dedicated-cpu
zonecfg:zonelx:dedicated-cpu> set ncpus=1-2
zonecfg:zonelx:dedicated-cpu> end
zonecfg:zonelx> add capped-memory
zonecfg:zonelx:capped-memory> set physical=256m
zonecfg:zonelx:capped-memory> set swap=128m
zonecfg:zonelx:capped-memory> set locked=50m
zonecfg:zonelx:capped-memory> end
zonecfg:zonelx> verify
zonecfg:zonelx> commit
zonecfg:zonelx> exit

La configuración de la memoria de tipo contenedor tambien la podemos realizar cuando el contenedor se esta ejecutando, a través del Resource Manager, asi:

# rcapadm -z zonelx -m 256m

Y lo mismo el area de swap:

# prctl -n zone.max-swap -v 128m -t privileged -r -e deny -i zone zonelx

Instalamos la imagen de CentOS 3.0...

# zoneadm -z zonelx install -d /export/home/un38134/centos_fs_image.tar.bz
Installing zone 'zonelx' at root directory '/opt/zones'
from archive '/export/home/un38134/centos_fs_image.tar.bz'

This process may take several minutes.
Setting up the initial lx brand environment.
System configuration modifications complete.

Installation of zone 'zonelx' completed successfully.

Details saved to log file:
"/opt/zones/root/var/log/zonelx.install.747.log"

# zoneadm list -iv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
1 zonelx running /opt/zones/zonelx lx shared
- zonepruebas installed /opt/zones/zonepruebas native shared

# zonecfg -z zonelx info
zonename: zonelx
zonepath: /opt/zones/zonelx
brand: lx
autoboot: false
bootargs: -m verbose
pool:
limitpriv:
scheduling-class:
ip-type: shared
net:
address: 10.73.130.249/24
physical: pcn0
capped-memory:
physical: 256M
[swap: 128M]
[locked: 50M]
rctl:
name: zone.max-swap
value: (priv=privileged,limit=134217728,action=deny)
rctl:
name: zone.max-locked-memory
value: (priv=privileged,limit=52428800,action=deny)

Arrancamos la zona.

# zoneadm -z zonelx boot

Y ya podemos acceder a nuestro contenedor con Linux.

# zlogin zonelx
[Conectado a la zona 'zonelx' pts/2]

Welcome to your shiny new Linux zone.

- The root password is 'root'. Please change it immediately.

- To enable networking goodness, see /etc/sysconfig/network.example.

- This message is in /etc/motd. Feel free to change it.

For anything more complicated, see:
http://opensolaris.org/os/community/brandz/

You have mail.

# uname -a
Linux zonelx 2.4.21 BrandZ fake linux i686 i686 i386 GNU/Linux

# ifconfig -a
eth0 Link encap:Ethernet HWaddr 00:0C:29:2D:04:A0
inet addr:10.73.130.249 Bcast:10.73.130.255 Mask:255.255.255.0
UP BROADCAST RUNNING SLAVE MTU:1500 Metric:1

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING SLAVE MTU:8232 Metric:1
~.

A diferencia con el articulo anterior de este mismo blog, hemos trasformado la zona virtual de tipo BrandZ en un contenedor con unos pocos parametros definidos en su configuración.

Firewall IPFilter

2007-09-11T17:47:00.002+02:00

Desde el punto de vista de la Seguridad, una de las nuevas funcionalidades (a parte de JASS, TCP_WRAPPER, RBAC y SMF) de Solaris 10 y OpenSolaris es la incorporación de IPFilter como herramienta de filtrado (tcp/udp) y NAT con el Soporte de Sun Microsystems.

En versiones anteriores de Solaris (a partir de la 8 y todavia compatible en 9), se incorporó de forma gratuita el producto SunScreen en su version Lite hasta la v3.1.

En este articulo vamos a configurar de forma sencilla la proteccion de nuestro sistema con unas simples reglas y entender su funcionamiento.

Inicializamos los modulos del Kernel.

# ipf -E

Y ya podemos activar el uso de este software, gestionandolo a través de SMF.

# svcadm enable ipfilter

# svcs | grep ipfilter
online 11:17:24 svc:/network/ipfilter:default

# tail -f /var/svc/log/network-ipfilter\:default.log
[ abr 25 18:14:26 Disabled. ]
[ abr 25 18:14:26 Rereading configuration. ]
[ abr 25 18:30:41 Disabled. ]
[ sep 11 11:17:11 Enabled. ]
[ sep 11 11:17:14 Executing start method ("/lib/svc/method/ipfilter start") ]
[ sep 11 11:17:24 Method "start" exited with status 0 ]

Luego ya podemos testear su estado, asi:

# ipfstat -iol
empty list for ipfilter(out)
empty list for ipfilter(in)

Esto es debido a que todavia no esta configurado. Tenemos que crear un fichero /etc/ipf/pfil.ap en el cual indicamos la interfaz sobre la que va a actuar este software, y el fichero /etc/ipf/ipf.conf en el cual implementamos nuestra politica de reglas de filtrado o NAT.

# ifconfig -a
lo0: flags=2001000849 mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
pcn0: flags=201000843 mtu 1500 index 2
inet 10.73.130.251 netmask ffffff00 broadcast 10.73.130.255
ether 0:c:29:ef:ed:da

# vi /etc/ipf/pfil.ap
P Filter pfil autopush setup
#
# See the autopush(1M) manpage for more information.
#
# Format of the entries in this file is:
#
#major minor lastminor modules
#iprb -1 0 pfil
#elxl -1 0 pfil
pcn0 -1 0 pfil
#e1000g -1 0 pfil
#bge -1 0 pfil
#nf -1 0 pfil
#fa -1 0 pfil
#ci -1 0 pfil
#el -1 0 pfil
#ipdptp -1 0 pfil
#lane -1 0 pfil
#dnet -1 0 pfil
#pcelx -1 0 pfil
#spwr -1 0 pfil

# vi /etc/ipf/ipf.conf
#
# ipf.conf
#
# IP Filter rules to be loaded during startup
#
# See ipf(4) manpage for more information on
# IP Filter rules syntax.

# Block any packets which are too short to be real
block in quick all with short
#
# drop and log any IP packets with options set in them.
block in all with ipopts
#
# Allow all traffic on loopback.
pass in quick on lo0 all
pass out quick on lo0 all
#
# Public Network. Block everything not explicity allowed.
#block in log on pcn0 all
block in log on pcn0 from any to any port = 22
block out on pcn0 all
#
# Allow pings out.
pass out quick on pcn0 proto icmp all keep state
#
# for testing, allow pings from ben and jerry
pass in quick on pcn0 proto icmp from 10.73.130.122/32 to 10.73.130.251/32
#
# Allow outbound state related packets.
pass out quick on pcn0 proto tcp/uDp from any to any keep state
#
# allow ssh from 172.16.0.0/16 only.
# pass in log quick on pcn0 from 172.16.0.0/16 to 172.16.1.100/32 port = 22
# Actually, allow ssh only from ben, jerry, MSU
pass in quick on pcn0 proto tcp from 10.73.130.122/32 to 10.73.130.251/32 port = 22

En esta sencilla configuración hemos bloqueado todo el trafico y unicamente permitimos desde la ip 10.73.130.122 acceder por ssh a la ip 10.73.130.251, ademas del trafico icmp.

Volvemos a reiniciar el servicio y listamos las reglas de nuevo.

# svcadm disable ipfilter
# svcadm enable ipfilter
# ipftsat -iol
pass out quick on lo0 all
block out on pcn0 all
pass out quick on pcn0 proto icmp from any to any keep state
pass out quick on pcn0 proto tcp/udp from any to any keep state
block in quick from any to any with short
block in from any to any with ipopts
pass in quick on lo0 all
block in log on pcn0 from any to any port = 22
pass in quick on pcn0 proto icmp from 10.73.130.122/32 to 10.73.130.251/32
pass in quick on pcn0 proto tcp from 10.73.130.122/32 to 10.73.130.251/32 port = ssh

Luego si lanzamos una conexión con un cliente ssh, desde la ip 10.73.130.68 con destino la ip 10.73.130.122, vemos facilmente como es rechazada:

# tail -f /var/adm/ipfilter.log
11/09/2007 19:11:41.430677 pcn0 @0:4 b 10.73.130.68,50315 -> 10.73.130.251,22 PR tcp len 20 44 -S IN

Y además las estadisticas desde que se inicio el servicio.

# ipfstat -hio
0 pass out quick on lo0 all
3 block out on pcn0 all
0 pass out quick on pcn0 proto icmp from any to any keep state
2 pass out quick on pcn0 proto tcp/udp from any to any keep state
0 block in quick from any to any with short
0 block in from any to any with ipopts
0 pass in quick on lo0 all
7 block in log on pcn0 from any to any port = 22
0 pass in quick on pcn0 proto icmp from 10.73.130.122/32 to 10.73.130.251/32
2 pass in quick on pcn0 proto tcp from 10.73.130.122/32 to 10.73.130.251/32 port = ssh

Pero si uno no esta demasiado familiarizado con este tipo de Firewalls a nivel de comandos, siempre podemos recurrir a la ultilización de alguna GUI. Para este particular FwBuilder es una de las mejores soluciones de código abierto compatible 100% con IpFilter y Solaris 10.

Discos SAN gobernados por VxVM

2007-09-03T17:51:00.001+02:00

En Solaris 10, si disponemos de una SAN de cualquier fabricante de almacenamiento (SUN, Hitachi, EMC, HP, IBM...), podemos acceder a los discos de dos formas:

1.- Utilizando el cliente de la SAN propio de cada fabricante. (Ej: Powerpath de EMC)

2.- Utilizando un cliente universal, como puede ser Veritas Volume Manager.

Antes de nada, tenemos que verificar que tenemos una correcta configuración hardware de las tarjetas de fibra (HBA) mediante las cuales vamos a conectar nuestro sistema a la SAN, a través de los switches de fibra.

En nuestro escenario particular utilizaremos dos tarjetas HBA de tipo Emulex, conectándonos a una cabina Symetrix de EMC y utilizando el módulo DMP del VxVM para la gestión de los discos.

Confirmamos que tenemos instalado el driver del fabricante de dichas HBAs.

# pkginfo | grep -i lpfc
system lpfc Emulex LightPulse FC SCSI/IP Host Bus Adapter driver
# pkginfo -l lpfc
PKGINST: lpfc
NAME: Emulex LightPulse FC SCSI/IP Host Bus Adapter driver
CATEGORY: system
ARCH: sparc
VERSION: Release 6.11c
BASEDIR: /
PSTAMP: sunv24020070207110814
INSTDATE: Mar 05 2007 16:19
STATUS: completely installed
FILES: 30 installed pathnames
16 shared pathnames
15 directories
9 executables
3690 blocks used (approx)

La configuración de las mismas reside fundamentalmente en dos ficheros /kernel/drv/lpfc.conf (identificación de los puertos "world wide name" (WWN) y los target de cada HBA, que presenta la cabina a nuestro sistema) y /kernel/drv/sd.conf (asociación de cada target y lun libre, asignado por el sistema a cada disco descubierto)

Y el paquete con todos los binarios que utilizaremos posteriormente (dependiente del anterior).

# pkginfo | grep HBAnyware
system HBAnyware Emulex HBAnyware FC Host Bus Adapter Remote Manager
# pkginfo -l HBAnyware
PKGINST: HBAnyware
NAME: Emulex HBAnyware FC Host Bus Adapter Remote Manager
CATEGORY: system
ARCH: sun4u
VERSION: 3.1a12
BASEDIR: /
PSTAMP: utilsun0420070103103238
INSTDATE: Mar 05 2007 16:26
STATUS: completely installed
FILES: 505 installed pathnames
10 shared pathnames
17 directories
24 executables
55388 blocks used (approx)

Tras la instalación de estos paquetes y el reinicio de nuestro sistema, podemos comprobar que a nivel software el sistema este correctamente configurado para soportar FCP.

# /usr/sbin/lpfc/lputil
LightPulse Common Utility for Solaris/SPARC. Version 2.0a13 (1/3/2006).
Copyright (c) 2005, Emulex Corporation
Emulex Fibre Channel Host Adapters Detected: 2
Host Adapter 0 (lpfc2) is an LP9K (Ready Mode)
Host Adapter 1 (lpfc3) is an LP9K (Ready Mode)
MAIN MENU
1. List Adapters
2. Adapter Information
3. Firmware Maintenance
4. Reset Adapter
5. Persistent Bindings
0. Exit
Enter choice => 2
ADAPTER INFORMATION MENU
1. PCI Configuration Parameters
2. Adapter Revision Levels
3. Wakeup Parameters
4. IEEE Address
5. Loop Map
6. Status & Counters
7. Link Status
8. Configuration Parameters
0. Return to Main Menu
Enter choice => 4
0. lpfc2
1. lpfc3
Select an adapter => 0
IEEE Address for Adapter 0:
[10000000] [C94951F4] <- WWN de la HBA

# format -e
Searching for disks...done
AVAILABLE DISK SELECTIONS:
0. c0t0d0
/pci@1f,4000/scsi@3/sd@0,0
1. c0t8d0
/pci@1f,4000/scsi@3/sd@8,0
2. c0t9d0
/pci@1f,4000/scsi@3/sd@9,0
3. c0t10d0
/pci@1f,4000/scsi@3/sd@a,0
4. c0t11d0
/pci@1f,4000/scsi@3/sd@b,0
5. c0t12d0
/pci@1f,4000/scsi@3/sd@c,0
6. c5t0d0
/pci@1f,4000/lpfc@2/sd@0,0
7. c5t0d117
/pci@1f,4000/lpfc@2/sd@0,75
8. c5t0d118
/pci@1f,4000/lpfc@2/sd@0,76
9. c5t0d119
/pci@1f,4000/lpfc@2/sd@0,77
10. c5t0d120
/pci@1f,4000/lpfc@2/sd@0,78
11. c5t0d121
/pci@1f,4000/lpfc@2/sd@0,79
12. c5t0d122
/pci@1f,4000/lpfc@2/sd@0,7a
13. c5t0d123
/pci@1f,4000/lpfc@2/sd@0,7b
14. c5t0d124
/pci@1f,4000/lpfc@2/sd@0,7c
15. c5t1d0
/pci@1f,4000/lpfc@2/sd@1,0
16. c5t1d117
/pci@1f,4000/lpfc@2/sd@1,75
17. c5t1d118
/pci@1f,4000/lpfc@2/sd@1,76
18. c5t1d119
/pci@1f,4000/lpfc@2/sd@1,77
19. c5t1d120
/pci@1f,4000/lpfc@2/sd@1,78
20. c5t1d121
/pci@1f,4000/lpfc@2/sd@1,79
21. c6t0d0
/pci@1f,4000/lpfc@4/sd@0,0
22. c6t0d117
/pci@1f,4000/lpfc@4/sd@0,75
23. c6t0d118
/pci@1f,4000/lpfc@4/sd@0,76
24. c6t0d119
/pci@1f,4000/lpfc@4/sd@0,77
25. c6t0d120
/pci@1f,4000/lpfc@4/sd@0,78
26. c6t0d121
/pci@1f,4000/lpfc@4/sd@0,79
27. c6t0d122
/pci@1f,4000/lpfc@4/sd@0,7a
28. c6t0d123
/pci@1f,4000/lpfc@4/sd@0,7b
29. c6t0d124
/pci@1f,4000/lpfc@4/sd@0,7c
30. c6t1d0
/pci@1f,4000/lpfc@4/sd@1,0
31. c6t1d117
/pci@1f,4000/lpfc@4/sd@1,75
32. c6t1d118
/pci@1f,4000/lpfc@4/sd@1,76
33. c6t1d119
/pci@1f,4000/lpfc@4/sd@1,77
34. c6t1d120
/pci@1f,4000/lpfc@4/sd@1,78
35. c6t1d121
/pci@1f,4000/lpfc@4/sd@1,79

Ya son visibles los discos de la región permitida de la SAN a la que tiene acceso nuestro sistema, luego podemos comenzar a instalar VxVM a traves del CD-ROM:

# mount -F hsfs -o ro /dev/dsk/c0t6d0s2 /opt
# cd /opt/software/
# ls
10_Recommended.zip fcaw
C500A5.TXT file_system
CO150A9.PRG getting_started.pdf
EMCPower.SOLARIS.5.0.0.GA.b141.tar gnu
EMCpower installer
LP6DUTIL.EXE lpfc
LP6DUTIL.doc perl
O150a9.txt readme.txt
authentication_service readme_Sol_2612.txt
cd393a0.awc samplescript.txt
cd393a0.zip storage_foundation
cdc393a0.awc storage_foundation_cluster_file_system
cluster_management_console storage_foundation_for_db2
cluster_server storage_foundation_for_oracle
cluster_server_agents storage_foundation_for_oracle_rac
co150a9.zip storage_foundation_for_sybase
emc volume_manager
fca-pci.pkg volume_replicator
fca-pci2612.tar windows

# ./installer -rsh
Storage Foundation and High Availability Solutions 5.0

Symantec Product Version Installed Licensed
===========================================================================
Veritas File System 5.0 yes
Veritas Volume Manager 5.0 yes
Veritas Volume Replicator 5.0 no
Veritas Storage Foundation 5.0 no
Veritas Storage Foundation for Oracle 5.0 no
Veritas Storage Foundation for DB2 no no
Veritas Storage Foundation for Sybase no no
Veritas Storage Foundation Cluster File System 5.0 no
Veritas Storage Foundation for Oracle RAC 5.0 no

Task Menu:

I) Install/Upgrade a Product C) Configure an Installed Product
L) License a Product P) Perform a Pre-Installation Check
U) Uninstall a Product D) View a Product Description
Q) Quit ?) Help

Enter a Task: [I,C,L,P,U,D,Q,?] Enter a Task: [I,C,L,P,U,D,Q,?] I
...

Una vez instalado y reiniciado de nuevo el sistema, listamos las controladoras:

# vxdmpadm listctlr all
CTLR-NAME ENCLR-TYPE STATE ENCLR-NAME
=====================================================
c0 Disk ENABLED Disk
c6 EMC ENABLED EMC1
c5 EMC ENABLED EMC1
c5 EMC ENABLED EMC0
c6 EMC ENABLED EMC0

Y los discos a los que podemos acceder a traves de ellas:

# vxdmpadm getsubpaths ctlr=c0
NAME STATE[A] PATH-TYPE[M] DMPNODENAME ENCLR-TYPE ENCLR-NAME ATTRS
================================================================================
c0t0d0s2 ENABLED(A) - c0t0d0s2 Disk Disk -
c0t8d0s2 ENABLED(A) - c0t8d0s2 Disk Disk -
c0t9d0 ENABLED(A) - c0t9d0 Disk Disk -
c0t10d0 ENABLED(A) - c0t10d0 Disk Disk -
c0t11d0 ENABLED(A) - c0t11d0 Disk Disk -
c0t12d0 ENABLED(A) - c0t12d0 Disk Disk -

La controladora c0 nos permite acceder a los discos locales, como podemos comprobar:

# cfgadm -al
Ap_Id Type Receptacle Occupant Condition
c0 scsi-bus connected configured unknown
c0::dsk/c0t0d0 disk connected configured unknown
c0::dsk/c0t6d0 CD-ROM connected configured unknown
c0::dsk/c0t8d0 disk connected configured unknown
c0::dsk/c0t9d0 disk connected configured unknown
c0::dsk/c0t10d0 disk connected configured unknown
c0::dsk/c0t11d0 disk connected configured unknown
c0::dsk/c0t12d0 disk connected configured unknown
c1 scsi-bus connected unconfigured unknown
c2 scsi-bus connected unconfigured unknown

# vxdmpadm getsubpaths ctlr=c6
NAME STATE[A] PATH-TYPE[M] DMPNODENAME ENCLR-TYPE ENCLR-NAME ATTRS
================================================================================
c6t0d117s2 ENABLED(A) - c5t0d117s2 EMC EMC1 -
c6t0d118s2 ENABLED(A) - c5t0d118s2 EMC EMC1 -
c6t0d119s2 ENABLED(A) - c5t0d119s2 EMC EMC1 -
c6t0d120s2 ENABLED(A) - c5t0d120s2 EMC EMC1 -
c6t0d121s2 ENABLED(A) - c5t0d121s2 EMC EMC1 -
c6t0d122s2 ENABLED(A) - c5t0d122s2 EMC EMC1 -
c6t0d123s2 ENABLED(A) - c5t0d123s2 EMC EMC1 -
c6t0d124s2 ENABLED(A) - c5t0d124s2 EMC EMC1 -
c6t1d117s2 ENABLED(A) - c6t1d117s2 EMC EMC0 -
c6t1d118s2 ENABLED(A) - c6t1d118s2 EMC EMC0 -
c6t1d119s2 ENABLED(A) - c6t1d119s2 EMC EMC0 -
c6t1d120s2 ENABLED(A) - c6t1d120s2 EMC EMC0 -
c6t1d121s2 ENABLED(A) - c6t1d121s2 EMC EMC0 -

# vxdmpadm getsubpaths ctlr=c5
NAME STATE[A] PATH-TYPE[M] DMPNODENAME ENCLR-TYPE ENCLR-NAME ATTRS
================================================================================
c5t0d117s2 ENABLED(A) - c5t0d117s2 EMC EMC1 -
c5t0d118s2 ENABLED(A) - c5t0d118s2 EMC EMC1 -
c5t0d119s2 ENABLED(A) - c5t0d119s2 EMC EMC1 -
c5t0d120s2 ENABLED(A) - c5t0d120s2 EMC EMC1 -
c5t0d121s2 ENABLED(A) - c5t0d121s2 EMC EMC1 -
c5t0d122s2 ENABLED(A) - c5t0d122s2 EMC EMC1 -
c5t0d123s2 ENABLED(A) - c5t0d123s2 EMC EMC1 -
c5t0d124s2 ENABLED(A) - c5t0d124s2 EMC EMC1 -
c5t1d117s2 ENABLED(A) - c5t1d117s2 EMC EMC0 -
c5t1d118s2 ENABLED(A) - c5t1d118s2 EMC EMC0 -
c5t1d119s2 ENABLED(A) - c5t1d119s2 EMC EMC0 -
c5t1d120s2 ENABLED(A) - c5t1d120s2 EMC EMC0 -
c5t1d121s2 ENABLED(A) - c5t1d121s2 EMC EMC0 -

Pero si listamos todos los discos que ve VxVM, es como si existieran el doble... aunque realmente son los mismos a través de la controladora c5 y c6, ya que lo único que cambia es la bandeja de la cabina por la que ataca cada una de las HBA (EMC1 o EMC2).

# vxdisk list
DEVICE TYPE DISK GROUP STATUS
c0t0d0s2 auto:sliced rootdisk rootdg online
c0t9d0 auto:sliced - - online
c0t10d0 auto:none - - online invalid
c0t11d0 auto:none - - online invalid
c0t12d0 auto:none - - online invalid
c5t0d117s2 auto:none - - online invalid
c5t0d118s2 auto:none - - online invalid
c5t0d119s2 auto:none - - online invalid
c5t0d120s2 auto:none - - online invalid
c5t0d121s2 auto:none - - online invalid
c5t0d122s2 auto:none - - online invalid
c5t0d123s2 auto:none - - online invalid
c5t0d124s2 auto:none - - online invalid
c5t1d117s2 auto:none - - online invalid
c5t1d118s2 auto:none - - online invalid
c5t1d119s2 auto:none - - online invalid
c5t1d120s2 auto:none - - online invalid
c5t1d121s2 auto:none - - online invalid
c6t1d117s2 auto:none - - online invalid
c6t1d118s2 auto:none - - online invalid
c6t1d119s2 auto:none - - online invalid
c6t1d120s2 auto:none - - online invalid
c6t1d121s2 auto:none - - online invalid
c6t0d117s2 auto:none - - online invalid
c6t0d118s2 auto:none - - online invalid
c6t0d119s2 auto:none - - online invalid
c6t0d120s2 auto:none - - online invalid
c6t0d121s2 auto:none - - online invalid
c6t0d122s2 auto:none - - online invalid
c6t0d123s2 auto:none - - online invalid
c6t0d124s2 auto:none - - online invalid

Realizamos un escaneo de los discos desde VxVM:

# vxdctl enable

Inicializamos 3 de los discos, es decir a partir de ese momento VxVM va a gestionar toda su informacion de forma completa.

# vxdisksetup -i c6t1d119
# vxdisksetup -i c6t1d120
# vxdisksetup -i c6t1d121

# vxdisk list | egrep "c6t1d119|c6t1d120s2|c6t1d121s2"
c6t1d119s2 auto:cdsdisk - - online
c6t1d120s2 auto:cdsdisk - - online
c6t1d121s2 auto:cdsdisk - - online

Creamos un grupo de discos denominado app_dg asignandole estos discos.

# vxdg init app_dg c6t1d119s2=c6t1d119
# vxdg -g app_dg adddisk c6t1d120s2=c6t1d120
# vxdg -g app_dg adddisk c6t1d121s2=c6t1d121

Y creamos un volumen test de 3GB de tipo stripe, el cual daremos formato VxFS y montaremos como filesystem /prueba:

# vxassist -g app_dg make test 3072m layout=stripe
# mkfs -F vxfs -o largefiles /dev/vx/rdsk/app_dg/test
# vxprint -g app_dg -th

dg app_dg default default 27000 1176279780.32.teras6

dm c6t1d119s2 c6t1d119s2 auto 65536 47452288 -
dm c6t1d120s2 c6t1d119s2 auto 65536 47452288 -
dm c6t1d121s2 c6t1d119s2 auto 65536 47452288 -

v test - ENABLED ACTIVE 2097152 SELECT - fsgen
pl test-01 test ENABLED ACTIVE 2097152 STRIPE - RW
sd c6t1d119s2-01 test-01 c6t1d119s2 0 2097152 0/0 c6t1d119 ENA
sd c6t1d120s2-01 test-01 c6t1d120s2 0 2097152 1/0 c6t1d120 ENA
sd c6t1d121s2-01 test-01 c6t1d121s2 0 2097152 2/0 c6t1d121 ENA

# mount -F vxfs /dev/vx/dsk/app_dg/test /prueba

Luego a parte de las bondades que nos proporcina una SAN en cuanto a rendimiento, replicacion y backup, hemos conseguido un filesystem VxFS gestionado por VxVM de una región de discos permitida de la SAN. La ventaja de este modelo es simple: si la controladora c6 que sirve una de las dos HBAs deja de funcionar, siempre podremos acceder a los datos por el camino que nos quedaría de la controladora c5 que sirve la otra HBA y además este cambio seria trasparante ya que lo realizaría el módulo DMP.

Adivinar contraseñas con DTRACE

2007-08-07T12:20:00.002+02:00

Una de las nuevas funcionalidades de Solaris 10 y Opensolaris reside en la incorporacion de todo un framewok de instrumentacion como DTRACE.

Si nos descargamos el DtraceToolKit, el cual es un conjunto de scripts dtrace, bien documentados y desarrollados directamente por la comunidad, podemos fijarmos en particular en la utilizacion de sshkeysnoop.d como una variante del script dtrace shellsnoop. En su ejecucion nos permite capturar todas las contraseñas (incluso a traves de ssh) que se establezcan desde nuestro sistema con destino otros hosts, asi:

# uname -iX
i86pcSystem = SunOS
Node = opensolaris
Release = 5.11
KernelID = snv_57
Machine = i86pc
BusType =
Serial =
Users =
OEM# = 0
Origin# = 1
NumCPU = 1

Identificado nuestro sistema, lanzamos el sshkeysnoop.d.

# pwd
/opt/DTT/Apps

# ./sshkeysnoop.d
UID PID PPID TYPE TEXT

Y esperamos que desde cualquier sesión de terminal o consola, algun usuario de nuestro sistema intente establecer una sesion ssh con otro host.

# ssh pepe@opensolaris
ContraseÃ±a:
Last login: Tue Aug 7 12:12:53 2007 from opensolaris
Sun Microsystems Inc. SunOS 5.11 snv_57 October 2007
$ bash
$ hostname
opensolaris

Esto es lo que observamos en la captura del sshkeysnoop.d.

# ./sshkeysnoop.d
UID PID PPID TYPE TEXT
0 10873 10852 cmd ssh pepe@opensolaris
lib/libc.so.1
0 10873 10852 key 8
0 10873 10852 key L
0 10873 10852 key u
0 10873 10852 key c
0 10873 10852 key a
0 10873 10852 key s
0 10873 10852 key 0
0 10873 10852 key 1
^C

Luego vemos claramente como en el sistema opensolaris, el usuario pepe tiene como contraseña para acceder 8Lucas01.

Zonas, Contenedores y recursos CPU

2007-08-02T16:12:00.002+02:00

Si tenemos dos Zonas definidas en nuestro sistema a parte de la global (zonepruebas y zonepruebas2), podemos gestionar sus consumos de recusros CPU a través del (FSS). Fair Share Scheduler: Este software permite asignar a cada aplicacion los recusos maximos de CPU del total de procesadores del sistema, por si se producen situaciones de competencia.

bash-3.00# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
7 zonepruebas running /zonas/pruebas native shared
9 zonepruebas2 running /zonas/pruebas2 native shared

Vemos como las zonas estan corriendo y podemos comenzar a definir los limites en los pooles que posteriormente asociaremos a cada una de ellas.

bash-3.00# cat > /etc/poolcfg
create pool zone1-pool ( string pool.scheduler = "FSS" )
create pool zone2-pool ( string pool.scheduler = "FSS" )
^C

Recargamos la configuración definida en el fichero /etc/poolcfg.

bash-3.00# pooladm -x; pooladm -s; poolcfg -f /etc/poolcfg ; pooladm -c

bash-3.00# psrset

Y la comprobamos:

bash-3.00# pooladm

system default
string system.comment
int system.version 1
boolean system.bind-default true
string system.poold.objectives wt-load

pool zone2-pool
int pool.sys_id 3
boolean pool.active true
boolean pool.default false
string pool.scheduler FSS
int pool.importance 1
string pool.comment
pset pset_default

pool pool_default
int pool.sys_id 0
boolean pool.active true
boolean pool.default true
int pool.importance 1
string pool.comment
pset pset_default

pool zone1-pool
int pool.sys_id 2
boolean pool.active true
boolean pool.default false
string pool.scheduler FSS
int pool.importance 1
string pool.comment
pset pset_default

pset pset_default
int pset.sys_id -1
boolean pset.default true
uint pset.min 1
uint pset.max 65536
string pset.units population
uint pset.load 9699
uint pset.size 1
string pset.comment

cpu
int cpu.sys_id 0
string cpu.comment
string cpu.status on-line

Si todo ha ido OK, podemos habilitar el FSS en nuestro anfitrion y reiniciarlo.

bash-3.00# dispadmin -d FSS

bash-3.00# hostname
opensolaris

bash-3.00# init 6

Al arrancar el anfitrión (zona global), comprobamos la gestión de recursos en los procesos del sistema mediante el FSS.

bash-3.00# ps -feac
UID PID PPID CLS PRI STIME TTY TIME CMD
root 0 0 SYS 96 14:38:21 ? 0:03 sched
root 1 0 FSS 39 14:38:24 ? 0:00 /sbin/init
root 2 0 SYS 98 14:38:24 ? 0:00 pageout
root 3 0 SYS 60 14:38:24 ? 0:00 fsflush
root 261 1 FSS 54 14:39:27 ? 0:01 /usr/lib/hal/hald --daemon=yes
root 7 1 FSS 59 14:38:28 ? 0:05 /lib/svc/bin/svc.startd
root 9 1 FSS 29 14:38:28 ? 0:11 /lib/svc/bin/svc.configd
root 342 1 FSS 59 14:39:52 ? 0:00 /usr/sbin/syslogd
root 333 305 FSS 57 14:39:51 ? 0:00 /usr/lib/saf/ttymon
root 295 262 FSS 59 14:39:34 ? 0:00 /usr/lib/hal/hald-addon-storage
un38134 468 467 FSS 1 14:43:00 syscon 0:00 -bash
root 472 468 FSS 59 14:43:02 syscon 0:00 -sh
root 163 1 FSS 59 14:39:11 ? 0:00 /usr/sbin/nscd
root 316 7 FSS 46 14:39:51 console 0:00 /usr/lib/saf/ttymon -g -d /dev/console -l console -m ldterm,ttcompat -h -p open
root 100 1 FSS 29 14:39:00 ? 0:00 /usr/lib/sysevent/syseventd
root 255 1 FSS 59 14:39:25 ? 0:01 /usr/lib/fm/fmd/fmd
root 127 1 FSS 54 14:39:05 ? 0:00 /usr/sbin/mdmonitord
root 133 1 FSS 58 14:39:06 ? 0:00 /usr/lib/power/powerd
root 460 1 FSS 3 14:40:55 ? 0:00 /usr/lib/sendmail -bd -q15m -C /etc/mail/local.cf
daemon 134 1 FSS 59 14:39:07 ? 0:00 /usr/lib/crypto/kcfd
smmsp 461 1 FSS 52 14:40:55 ? 0:00 /usr/lib/sendmail -Ac -q15m
root 121 1 FSS 57 14:39:03 ? 0:00 /usr/lib/picl/picld
root 190 1 FSS 53 14:39:14 ? 0:00 /usr/sbin/cron
root 132 1 FSS 29 14:39:06 ? 0:00 devfsadmd
un38134 467 464 FSS 59 14:43:00 ? 0:00 /usr/lib/ssh/sshd
root 262 261 FSS 59 14:39:28 ? 0:00 hald-runner
root 315 1 FSS 59 14:39:51 ? 0:00 /usr/lib/rmvolmgr -s
root 305 7 FSS 58 14:39:50 ? 0:00 /usr/lib/saf/sac -t 300
daemon 242 1 FSS 56 14:39:19 ? 0:00 /usr/lib/dbus-daemon --system
root 367 1 FSS 1 14:39:55 ? 0:00 /usr/lib/ssh/sshd
root 476 472 FSS 1 14:43:06 syscon 0:00 bash
root 318 1 FSS 58 14:39:51 ? 0:00 /usr/lib/utmpd
root 477 476 FSS 59 14:43:14 syscon 0:00 ps -feac
root 387 1 FSS 17 14:39:56 ? 0:00 /usr/perl5/bin/perl /usr/lib/intrd
noaccess 458 1 FSS 57 14:40:18 ? 0:13 /usr/java/bin/java -server -Xmx128m -XX:+BackgroundCompilation -XX:PermSize=32m
root 464 367 FSS 59 14:42:44 ? 0:00 /usr/lib/ssh/sshd

En este momento ya podemos asociar los valores definidos en los distintos pooles para cada una de nuestras zonas, convirtiendolas en Contenedores.

bash-3.00# zonecfg -z zonepruebas
zonecfg:zonepruebas> set pool=zone1-pool
zonecfg:zonepruebas> add rctl
zonecfg:zonepruebas:rctl> set name=zone.cpu-shares
zonecfg:zonepruebas:rctl> add value (priv=privileged,limit=30,action=none)
zonecfg:zonepruebas:rctl> end
zonecfg:zonepruebas> verify
zonecfg:zonepruebas> exit

bash-3.00# zonecfg -z zonepruebas2
zonecfg:zonepruebas> set pool=zone1-pool
zonecfg:zonepruebas> add rctl
zonecfg:zonepruebas:rctl> set name=zone.cpu-shares
zonecfg:zonepruebas:rctl> add value (priv=privileged,limit=15,action=none)
zonecfg:zonepruebas:rctl> end
zonecfg:zonepruebas> verify
zonecfg:zonepruebas> exit

bash-3.00# zoneadm list -cv
ID NAME STATUS PATH BRAND IP
0 global running / native shared
7 zonepruebas installed /zonas/pruebas native shared
9 zonepruebas2 installed /zonas/pruebas2 native shared

Arrancamos las zonas zonepruebas y zonepruebas2.

bash-3.00# zoneadm -z zonepruebas boot

bash-3.00# zoneadm -z zonepruebas2 boot

y ademas podemos comprobar la gestión de recursos de ambas zonas.

bash-3.00# zonefss -l
ID NAME SHARES
0 global 1
7 zonepruebas 30
9 zonepruebas2 15

Vamos a utilizar este scrpit en Perl para estresar las zonas y medir sus consumo de CPU del total de procesadores del sistema.

bash-3.00# more cpuhog.pl
#!/usr/bin/perl
print "eating the CPUs\n";
foreach $i (1..16) {
$pid = fork();
last if $pid == 0;
print "created PID $pid\n";
}
while (1) {
$x++;
}

Por tanto, ejecutamos el cpuhog.pl tanto en el solaris anfitrion(zona global), como en las zonas definidas zonepruebas y zonepruebas2 y obervamos que al establecerse competencia por el uso de todos los recursos de CPU del sistema nunca se limitan los limites establecidos a traves del FSS.

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3825 root 3272K 1112K run 54 0 0:00:04 3,5% cpuhog.pl/1
3821 root 3272K 1112K run 54 0 0:00:03 3,4% cpuhog.pl/1
3819 root 3272K 1112K run 52 0 0:00:03 3,3% cpuhog.pl/1
3830 root 3272K 1112K run 52 0 0:00:03 3,3% cpuhog.pl/1
3829 root 3272K 1112K run 54 0 0:00:04 3,2% cpuhog.pl/1
3827 root 3272K 1112K run 51 0 0:00:03 3,2% cpuhog.pl/1
3815 root 3272K 1112K run 54 0 0:00:03 3,1% cpuhog.pl/1
3826 root 3272K 1112K run 54 0 0:00:03 3,1% cpuhog.pl/1
3807 root 3272K 1176K run 51 0 0:00:04 3,0% cpuhog.pl/1
3817 root 3272K 1112K run 54 0 0:00:03 3,0% cpuhog.pl/1
3828 root 3272K 1112K run 52 0 0:00:03 3,0% cpuhog.pl/1
3813 root 3272K 1112K run 54 0 0:00:03 3,0% cpuhog.pl/1
3823 root 3272K 1112K run 52 0 0:00:03 3,0% cpuhog.pl/1
3811 root 3272K 1112K run 52 0 0:00:04 2,9% cpuhog.pl/1
3805 root 3276K 1996K run 53 0 0:00:03 2,8% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:01:24 52% zonepruebas
9 39 98M 91M 11% 0:01:01 32% zonepruebas2
0 54 113M 111M 13% 0:00:46 7,8% global

Total: 131 processes, 452 lwps, load averages: 52,23, 22,69, 16,04

Pero si matamos el proceso cpuhog.pl de las zona zonepruebas2 unicamente, el FSS permite a la zona zonepruebas (conde si corre todavia el cpuhog.pl) utilizar la suma de los limites de ambas en cuanto a su utilización de los recursos de CPU del sistema, ya que todavia entra en competencia con el anfitrion (zona global), asi:

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3827 root 3272K 1112K run 59 0 0:00:11 6,9% cpuhog.pl/1
3830 root 3272K 1112K run 59 0 0:00:10 5,0% cpuhog.pl/1
3805 root 3276K 1996K run 59 0 0:00:10 4,9% cpuhog.pl/1
3811 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3825 root 3272K 1112K run 59 0 0:00:11 4,8% cpuhog.pl/1
3808 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3809 root 3272K 1112K run 59 0 0:00:11 4,8% cpuhog.pl/1
3823 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3815 root 3272K 1112K run 59 0 0:00:10 4,8% cpuhog.pl/1
3807 root 3272K 1176K run 59 0 0:00:11 4,7% cpuhog.pl/1
3813 root 3272K 1112K run 59 0 0:00:10 4,7% cpuhog.pl/1
3826 root 3272K 1112K run 59 0 0:00:10 4,7% cpuhog.pl/1
3828 root 3272K 1112K run 59 0 0:00:10 4,7% cpuhog.pl/1
3819 root 3272K 1112K run 59 0 0:00:10 4,6% cpuhog.pl/1
3817 root 3272K 1112K run 59 0 0:00:10 4,6% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:03:23 82% zonepruebas
0 54 113M 111M 13% 0:01:07 13% global
9 22 93M 88M 11% 0:00:23 0,1% zonepruebas2

Total: 114 processes, 435 lwps, load averages: 43,77, 32,25, 20,90

Y unicamente consumira practicamente el 100% de la CPU del sistema, cuando matamos el proceso cpuhog.pl en el anfitrion (zona global), asi:

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3813 root 3272K 1112K run 1 0 0:00:21 5,7% cpuhog.pl/1
3807 root 3272K 1176K run 2 0 0:00:21 5,7% cpuhog.pl/1
3828 root 3272K 1112K run 1 0 0:00:20 5,7% cpuhog.pl/1
3830 root 3272K 1112K run 1 0 0:00:20 5,6% cpuhog.pl/1
3809 root 3272K 1112K run 1 0 0:00:21 5,5% cpuhog.pl/1
3808 root 3272K 1112K run 3 0 0:00:21 5,5% cpuhog.pl/1
3826 root 3272K 1112K run 1 0 0:00:20 5,5% cpuhog.pl/1
3829 root 3272K 1112K run 3 0 0:00:21 5,5% cpuhog.pl/1
3821 root 3272K 1112K run 1 0 0:00:21 5,5% cpuhog.pl/1
3825 root 3272K 1112K run 1 0 0:00:21 5,5% cpuhog.pl/1
3811 root 3272K 1112K run 2 0 0:00:21 5,4% cpuhog.pl/1
3823 root 3272K 1112K run 17 0 0:00:20 5,3% cpuhog.pl/1
3805 root 3276K 1996K run 15 0 0:00:21 5,3% cpuhog.pl/1
3815 root 3272K 1112K run 3 0 0:00:20 5,3% cpuhog.pl/1
3819 root 3272K 1112K run 8 0 0:00:20 5,2% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:06:18 94% zonepruebas
0 37 108M 109M 13% 0:00:49 3,8% global
9 22 93M 88M 11% 0:00:23 0,1% zonepruebas2

Total: 97 processes, 418 lwps, load averages: 29,05, 33,26, 23,69

Y todo vuelve a la normalidad cuando matamos el proceso cpuhog.pl en la zona zonepruebas.

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3779 root 5660K 3504K cpu0 1 0 0:00:08 3,0% prstat/1
3769 un38134 10M 2400K sleep 59 0 0:00:00 0,3% sshd/1
456 noaccess 77M 53M sleep 56 0 0:00:29 0,2% java/24
3234 noaccess 76M 53M sleep 52 0 0:00:15 0,1% java/24
3600 noaccess 78M 55M sleep 56 0 0:00:13 0,1% java/24
3482 root 3456K 1684K sleep 59 0 0:00:00 0,0% syslogd/11
3267 root 7904K 2020K sleep 59 0 0:00:00 0,0% sendmail/1
3609 root 7904K 2024K sleep 59 0 0:00:00 0,0% sendmail/1
125 root 1556K 1104K sleep 6 0 0:00:00 0,0% powerd/3
121 root 2984K 1976K sleep 29 0 0:00:00 0,0% picld/4
315 root 2096K 1368K sleep 59 0 0:00:00 0,0% hald-addon-stor/1
307 root 1232K 844K sleep 59 0 0:00:00 0,0% utmpd/1
308 root 1920K 1160K sleep 59 0 0:00:00 0,0% sac/1
291 root 5260K 3672K sleep 59 0 0:00:00 0,0% hald/4
132 root 5748K 2404K sleep 29 0 0:00:00 0,0% mdmonitord/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
0 37 108M 109M 13% 0:00:56 3,5% global
7 21 89M 84M 10% 0:00:28 0,2% zonepruebas
9 22 93M 88M 11% 0:00:23 0,1% zonepruebas2

Total: 80 processes, 401 lwps, load averages: 11,29, 25,84, 22,50

Pero podemos asegurarnos que el anfitrion (zona global) tenga asegurado un limite en modo privilegiado del total de recursos de CPU para la ejecucion de sus procesos al igual que hemos realizado con las Zonas zonepruebas y zonepruebas2.

bash-3.00# prctl -n zone.cpu-shares -i zone global
zone: 0: global
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.cpu-shares
privileged 1 - none -
system 65,5K max none -
bash-3.00# prctl -n zone.cpu-shares -v 20 -r -i zone global

bash-3.00# prctl -n zone.cpu-shares -i zone global
zone: 0: global
NAME PRIVILEGE VALUE FLAG ACTION RECIPIENT
zone.cpu-shares
privileged 20 - none -
system 65,5K max none -

bash-3.00# zonefss -l
ID NAME SHARES
0 global 20
7 zonepruebas 30
9 zonepruebas2 15

Luego si ejecutamos de nuevo el script cpuhog.pl tanto en el anfitrion, como en las zonas zonepruebas y zonepruebas2, podemos ver que el limte de consumo de los recursos CPU por parte de la zona global ha aumentado significativamente.

bash-3.00# prstat -Z
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3918 root 3272K 1112K run 43 0 0:00:01 2,9% cpuhog.pl/1
3893 root 3272K 1176K run 45 0 0:00:01 2,7% cpuhog.pl/1
3899 root 3272K 1112K run 45 0 0:00:01 2,6% cpuhog.pl/1
3917 root 3272K 1112K run 45 0 0:00:01 2,5% cpuhog.pl/1
3916 root 3272K 1112K run 1 0 0:00:01 2,3% cpuhog.pl/1
3911 root 3272K 1112K run 3 0 0:00:01 2,3% cpuhog.pl/1
3914 root 3272K 1112K run 2 0 0:00:01 2,3% cpuhog.pl/1
3903 root 3272K 1112K run 3 0 0:00:01 2,2% cpuhog.pl/1
3895 root 3272K 1112K run 3 0 0:00:01 2,2% cpuhog.pl/1
3871 root 3272K 1108K run 48 0 0:00:01 2,2% cpuhog.pl/1
3909 root 3272K 1112K run 45 0 0:00:01 2,1% cpuhog.pl/1
3915 root 3272K 1112K run 33 0 0:00:01 2,1% cpuhog.pl/1
3897 root 3272K 1112K run 17 0 0:00:01 2,1% cpuhog.pl/1
3891 root 3276K 1996K run 3 0 0:00:01 2,0% cpuhog.pl/1
3880 root 3272K 1108K run 24 0 0:00:01 2,0% cpuhog.pl/1
3888 root 3272K 1108K run 27 0 0:00:01 1,9% cpuhog.pl/1
3906 root 3272K 1112K run 1 0 0:00:01 1,9% cpuhog.pl/1
3872 root 3272K 1108K run 44 0 0:00:01 1,9% cpuhog.pl/1
3867 root 5660K 3504K cpu0 53 0 0:00:01 1,9% prstat/1
3901 root 3272K 1112K run 45 0 0:00:01 1,9% cpuhog.pl/1
3877 root 3272K 1108K run 48 0 0:00:01 1,8% cpuhog.pl/1
ZONEID NPROC SWAP RSS MEMORY TIME CPU ZONE
7 38 94M 87M 11% 0:00:47 37% zonepruebas
0 54 113M 111M 13% 0:01:06 31% global
9 39 98M 91M 11% 0:00:32 24% zonepruebas2

Total: 131 processes, 452 lwps, load averages: 34,82, 11,46, 11,51

Como conclusión podemos ver que con el mecanismo de pooles de Solaris 10 y Opensolaris asignamos mediante el FSS los recursos de CPU del total de nuestro sistema (2, 4, 8, 16, etc...) a cada una de las Zonas, convirtiendolas en contenedores que nunca superaran su umbral definido como consumo maximo.

SMF y Privilegios

2007-07-30T18:51:00.001+02:00

Ha diferencia de las versiones anteriores de Solaris 6 y 7 donde para establecer privilegios teniamos que recurrir a software externo al sistema, como SUDO... y Solaris 8, 9 donde podiamos realizar este tipo de acciones con RBAC ya como parte del mismo. En Solaris 10 y OpenSolaris con la inclusión de SMF (Service Management Facility) la pespectiva cambia y podemos ser capaces de definir que usuario y que acciones puede realizar (parar, arrancar...) sobre un servicio del sistema que incluso levante un socket tcp/udp por debajo del puerto 1024 sin ser root.

En este ejemplo lo vamos a realizar con Apache2 gestionado como servicio a traves de SMF.

# svcs apache2
STATE STIME FMRI
disabled 19:12:02 svc:/network/http:apache2
# svcadm -v enable -s apache2
svc:/network/http:apache2 enabled.
# ps -aef | grep apache | grep -v grep
webservd 14836 14835 0 15:25:04 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 14837 14835 0 15:25:04 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 14839 14835 0 15:25:04 ? 0:00 /usr/apache2/bin/httpd -k start
root 14835 10895 0 15:25:03 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 14838 14835 0 15:25:04 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 14840 14835 0 15:25:04 ? 0:00 /usr/apache2/bin/httpd -k start
# ptree 14835
10895 zsched
14835 /usr/apache2/bin/httpd -k start
14836 /usr/apache2/bin/httpd -k start
14837 /usr/apache2/bin/httpd -k start
14838 /usr/apache2/bin/httpd -k start
14839 /usr/apache2/bin/httpd -k start
14840 /usr/apache2/bin/httpd -k start

Vemos como por defecto el proceso que realmente levanta el socket abierto en el puerto tcp 80 es iniciado como root y no tiene ningun tipo de privilegios.

# ppriv -S 14835
14835: /usr/apache2/bin/httpd -k start
flags =
E: zone
I: basic
P: zone
L: zone

Esto lo vamos a cambiar para el usuario webservd, asi:

# svcadm -v disable svc:/network/http:apache2
svc:/network/http:apache2 inhabilitado.
# svccfg -s apache2
svc:/network/http:apache2> setprop start/user = astring: webservd
svc:/network/http:apache2> setprop start/group = astring: webservd
svc:/network/http:apache2> setprop start/privileges = astring:
basic,!proc_session,!proc_info,!file_link_any,net_privaddr
svc:/network/http:apache2> setprop start/limit_privileges = astring: :default
svc:/network/http:apache2> setprop start/use_profile = boolean: false
svc:/network/http:apache2> setprop start/supp_groups = astring: :default
svc:/network/http:apache2> setprop start/working_directory = astring: :default
svc:/network/http:apache2> setprop start/project = astring: :default
svc:/network/http:apache2> setprop start/resource_pool = astring: :default
svc:/network/http:apache2> end
# svcprop -v -p start apache2
start/exec astring /lib/svc/method/http-apache2\ start
start/timeout_seconds count 60
start/type astring method
start/user astring webservd
start/group astring webservd
start/privileges astring
basic,!proc_session,!proc_info,!file_link_any,net_privaddr
start/limit_privileges astring :default
start/use_profile boolean false
start/supp_groups astring :default
start/working_directory astring :default
start/project astring :default
start/resource_pool astring :default
# svcadm -v refresh apache2
Action refresh set for svc:/network/http:apache2.
# svcadm -v enable -s apache2
svc:/network/http:apache2 habilitado.
# ps -fea|grep apache
webservd 3957 3953 0 19:21:13 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 3956 3953 1 19:21:13 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 3953 1 2 19:21:11 ? 0:01 /usr/apache2/bin/httpd -k start
webservd 3955 3953 1 19:21:13 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 3954 3953 0 19:21:13 ? 0:00 /usr/apache2/bin/httpd -k start
webservd 3958 3953 0 19:21:13 ? 0:00 /usr/apache2/bin/httpd -k start
# netstat -an|grep -i listen
*.22 *.* 0 0 49152 0 LISTEN
*.111 *.* 0 0 49152 0 LISTEN
*.59597 *.* 0 0 49152 0 LISTEN
*.80 *.* 0 0 49152 0 LISTEN
*.22 *.* 0 0 49152 0 LISTEN
*.80 *.* 0 0 49152 0 LISTEN

Y teniendo en cuenta lo que significa cada privilegios, vemos los que le hemos asignado.

# ppriv -v -l proc_exec proc_fork net_privaddr
proc_exec
Allows a process to call execve().
proc_fork
Allows a process to call fork1()/forkall()/vfork()
Configuring the Apache2 Service 7
net_privaddr
Allows a process to bind to a privileged port number.
The privilege port numbers are 1-1023 (the traditional
UNIX privileged ports) as well as those ports marked as
"udp/tcp_extra_priv_ports" with the exception of the ports
reserved for use by NFS.
# ppriv -S 3953
3953: /usr/apache2/bin/httpd -k start
flags =
E: net_privaddr,proc_exec,proc_fork
I: net_privaddr,proc_exec,proc_fork
P: net_privaddr,proc_exec,proc_fork
L: all

Luego hemos conseguido que el usuario webservd sea capaz de arrancar y para el servicio apache2, levantando un socket en el puerto tcp 80 sin necesidad de cambiar la identidad a root en ningún momento.

Habilitar SAR

2007-07-30T10:37:00.000+02:00

A diferencia de como podiamos habilitar este comando en versiones antiguas de Solaris (9 y anteriores), asi:

# vi /etc/init.d/perf
if [ -z "$_INIT_RUN_LEVEL" ]; then
set -- `/usr/bin/who -r`
_INIT_RUN_LEVEL="$7"
_INIT_RUN_NPREV="$8"
_INIT_PREV_LEVEL="$9"
fi

if [ $_INIT_RUN_LEVEL -ge 2 -a $_INIT_RUN_LEVEL -le 4 -a \
$_INIT_RUN_NPREV -eq 0 -a $ $_INIT_PREV_LEVEL = 1 -o \
$_INIT_PREV_LEVEL = S $ ]; then

/usr/bin/su sys -c "/usr/lib/sa/sadc /var/adm/sa/sa`date +%d`"
fi

Descomentando las lineas en negrita, y ejecutando este script:

# /etc/init.d/perf
# sar
10:43:26 unix restarts
Average 0 0 0 100
# uname -a
SunOS alfacar 5.9 Generic_118558-35 sun4u sparc SUNW,Ultra-5_10

Unicamente nos quedaría comprobar que todo queda listo en el cron.

# crontab -l sys
0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A

En Solaris 10 y OpenSolaris, con la aparición de SMF (Service Management Facility) como gestor de los distintos procesos de arranque del sistema, manteniendo todavia compatibilidad con los clásicos niveles de ejecución (Run Levels), se realiza de forma diferente:

# sar
sar: can't open /var/adm/sa/sa30
No such file or directory
# svcs |grep sa
online 10:38:51 svc:/system/sac:default
# svcadm enable svc:/system/sar:default
# svcs |grep sar
online 10:43:58 svc:/system/sar:default
# sar
SunOS opensolaris 5.11 snv_57 i86pc 07/30/2007
10:43:58 %usr %sys %wio %idle
10:43:58 unix restarts
# uname -a
SunOS opensolaris 5.11 snv_57 i86pc i386 i86pc
# crontab -l sys
0 * * * 0-6 /usr/lib/sa/sa1
20,40 8-17 * * 1-5 /usr/lib/sa/sa1
5 18 * * 1-5 /usr/lib/sa/sa2 -s 8:00 -e 18:01 -i 1200 -A
# svcs | grep cron
online 11:00:11 svc:/system/cron:default
# svcadm restart svc:/system/cron:default
# tail -f /var/cron/log
! ******* CRON ABORTED ******** lun jul 30 11:02:55 2007
! *** cron started *** pid = 567 lun jul 30 11:02:55 2007

Install Server en Solaris

2007-07-27T08:45:00.000+02:00

Si alguna vez habeis tenido que instalar varias maquinas Sun con cualquiera de las distintas versiones de Solaris y unicamnete una de ellas disponia de unidad de CD-ROM, aqui os dejo un resumen rapido de como generar un Install Server a partir del cual instalar el resto de sistemas:

(Lo he verificado tanto con Solaris 8, como con Solaris 9 y en breve lo confirmare para Solaris 10 y OpenSolaris)

1.- Insertar el CD-ROM de instalacion de Solaris etiquetado Software 1 de 2
2.- Montarlo manualmente o automaticamente a través del demonio vold
3.- # mkdir /var/Solaris8
4.- # cd /cdrom/sol_8_sparc/s0/Solaris_8/Tools
5.- # ./setup_install_server /var/Solaris8
6.- Cuando termine este proceso, sacar el CD-ROM anterior e insertar el denominado Solaris Software 2 de 2
7.- Montarlo manualmente o automaticamente a través del demonio vold
8.- # cd /cdrom/sol_8_sparc_2/Solaris_8/Tools
9.- # ./add_to_install_server /var/Solaris8
10.- Cuando termine este proceso ya tenemos nuestro Install Server generado con la imagen de Solaris 8 que hemos creado en /var/Solaris8.

Ahora unicamente nos queda registrar los clientes que queremos instalar a traves de la red y arrancarlos adecuadamente a traves de la OBP.

(*) En el Install Server tenemos que declarar los clientes a instalar mediante este método.

1.- Dar de alta la MAC de la tarjeta de red a través de la cual vamos a instalar el Solaris cliente, en el fichero /etc/ethers del Servidor de esta instalación.
08:00:20:C2:36:68 sun-001
2.- Dar de alta la IP del Solaris cliente, en el fichero /etc/hosts del Servidor de este instalación.
10.73.130.15 sun-001
3.- Verificar la siguiente entrada en el ficero /etc/nsswitch.conf del Servidor de esta instalación:
bootparams: files
4.- Dar de alta (en el Servidor) el cliente teniendo en cuenta la plataforma de la maquina Sun (en este caso sun4u):
# cd /var/Solaris8/Solaris_8/Tools
# ./add_install_client sun-001 sun4u

(*) Una vez finalizado este proceso, encendemos la maquina Sun a instalar y una vez en la OBP, arrancamos de red:

ok boot net

Hostname en Solaris

2007-07-26T16:23:00.001+02:00

Seguro que en mas de una ocasión, tras el proceso de instalación de las distintas versiones de Solaris, habeis necesitado cambiar el hostname de vuestro sistema (cosa que no tiene nada que ver ni con los interfaces de red, ni con la resolución de nombres del mismo).

Aqui os dejo una guia rapida de como cambiarlo:

1.- Una vez localizado el mismo:

# hostname
pluton

2.- Teneis que cambiar el valor de este literal (pluton) en los siguientes ficheros:

/etc/hosts
/etc/hostname.xxx
(Siendo xxx el interface afectado)
/etc/nodename
/etc/net/ticotsord/hosts
/etc/net/ticots/hosts
/etc/net/ticlts/hosts

3.- Reiniciamos y listo.

# init 6

USB & Solaris 10

2007-07-23T16:34:00.000+02:00

Aqui os dejo un breve manual "paso a paso" acerca de como montar nuestra llave USB bajo Solaris:

1.- Pincha nuestro Pen Drive en el equipo PC.
2.- # mkdir /rmdisk
3.- # /etc/init.d/volmgt stop
4.- # /etc/init.d/volmgt start
5.- # mount | grep rmdisk

Si en este orden no ha funcionado, este otro metodo es infalible:

1.- # /etc/init.d/volmgt stop
2.- # iostat -En
3.- Pinchar la llave USB
4.- # mount -F pcfs /dev/dsk/c2t0d0p0:c /mnt
ó
# mount -F pcfs /dev/dsk/c1t0d0p0:c /mnt

Availability Suite

2007-07-17T09:22:00.003+02:00

Tras la adquisición de StorageTek por parte de Sun Microsystems, en su política de desarrollar y contribuir a las comunidades de código abierto, Sun ha liberado la "Availability Suite" de StorageTek y ya es un proyecto mas dentro de OpenSolaris.

Es una magnifica noticia, tener la posibilidad de comprender como se implementan tecnologías como "Remote Mirror Copy" y "Point in Time Copy" basadas en Replicación TCP/IP algo fundamental en los proyectos de Consolidación y Respaldo de las grandes compañias.

HA Clusters

2007-07-17T09:22:00.002+02:00

Otro punto fundamental en el Desarrollo de OpenSolaris basado en comunidades de código abierto, ha sido el reciente anuncio por parte de Sun Microsystem de liberar el código de su software de alta disponibilidad: Sun Cluster 3.X como proyecto bajo este modelo.

Es otra magnifica noticia, ya que actualmente existian proyectos similares (heartbeat, kimberlite, HA/FST) en esta misma direccion, pero sin la robustez, ni el numero de agentes disponibles para los distintos productos de mercado que podemos monitorizar con el mismo.

Presentacion SVM / ZFS

2007-07-16T17:43:00.002+02:00

En breve creare una entrada que contendrá las ultimas novedades "no incluidas" en la presentación que realizé sobre las distintas herramientas de gestión del Almacenamiento de OpenSolaris, en el OpenSolaris Day 2007.

Mientras, un pequeño avance:

1.- Hotspare en SVM (Solaris Volume Manager)
2.- Stripe en ZFS (Zettabyte File System)
3.- Hotspare en ZFS (Zettabyte File System)

Lo prometido es deuda, asi que aqui van las ultimas funcionalidades probadas en OpenSolaris:

1.- Partimos de la siguiente configuracion de "soft partitions":

bash-3.00# metastat -p
d70 -p /dev/rdsk/c0d0s6 -o 1843210 -b 204800
d69 -p /dev/rdsk/c0d0s6 -o 1638409 -b 204800
d68 -p /dev/rdsk/c0d0s6 -o 1433608 -b 204800
d67 -p /dev/rdsk/c0d0s6 -o 1228807 -b 204800
d66 -p /dev/rdsk/c0d0s6 -o 1024006 -b 204800
d65 -p /dev/rdsk/c0d0s6 -o 819205 -b 204800
d64 -p /dev/rdsk/c0d0s6 -o 614404 -b 204800
d63 -p /dev/rdsk/c0d0s6 -o 409603 -b 204800
d62 -p /dev/rdsk/c0d0s6 -o 204802 -b 204800
d61 -p /dev/rdsk/c0d0s6 -o 1 -b 204800

Realizamos un metadispositivo de tipo RAID 1 d50, con un pool hotspare denominado hspool01, asi:

bash-3.00# metainit hspool01 /dev/md/dsk/d63 /dev/md/dsk/d64
hspool01: Agrupación de repuestos en marcha configurada
bash-3.00# metainit d51 1 1 /dev/md/dsk/d61 -h hspool01
d51: Concatenación/reparto está configurado
bash-3.00# metainit d52 1 1 /dev/md/dsk/d62 -h hspool01
d52: Concatenación/reparto está configurado
bash-3.00# metainit d50 -m d51
d50: Duplicación configurada
bash-3.00# metattach d50 d52
d50: subduplicación d52 is attached
bash-3.00# metastat -p d50
d50 -m /dev/md/rdsk/d51 /dev/md/rdsk/d52 1
d51 1 1 /dev/md/rdsk/d61 -h hspool01
d61 -p /dev/rdsk/c0d0s6 -o 1 -b 204800
d52 1 1 /dev/md/rdsk/d62 -h hspool01
d62 -p /dev/rdsk/c0d0s6 -o 204802 -b 204800

bash-3.00# metastat -t d50
d50: Duplicación
Subduplicación 0: d51
Estado: Correcto Wed Jul 18 10:52:19 2007
Subduplicación 1: d52
Estado: Correcto Wed Jul 18 10:52:33 2007
Paso: 1
Opción de lectura: roundrobin (predeterminado)
Opción de escritura: parallel (predeterminado)
Tamaño: 204800 bloques (100 MB)

d51: Subduplicación de d50
Estado: Correcto Wed Jul 18 10:52:19 2007
Agrupación de repuestos en marcha: hspool01
Tamaño: 204800 bloques (100 MB)
Banda 0:
Dispositivo Iniciar Base datos Estado Reubic Repuesto en marcha Hora
d61 0 No Correcto No Wed Jul 18 10:52:00 2007

d61: Partición por software
Dispositivo: c0d0s6
Estado: Correcto
Tamaño: 204800 bloques (100 MB)
Dispositivo Bloque de in Base Reubic
c0d0s6 0 No Sí

Extens Bloque de inicio Número de bloques
0 1 204800

d52: Subduplicación de d50
Estado: Correcto Wed Jul 18 10:52:33 2007
Agrupación de repuestos en marcha: hspool01
Tamaño: 204800 bloques (100 MB)
Banda 0:
Dispositivo Iniciar Base datos Estado Reubic Repuesto en marcha Hora
d62 0 No Correcto No Wed Jul 18 10:52:08 2007

d62: Partición por software
Dispositivo: c0d0s6
Estado: Correcto
Tamaño: 204800 bloques (100 MB)
Dispositivo Bloque de in Base Reubic
c0d0s6 0 No Sí

Extens Bloque de inicio Número de bloques
0 204802 204800

Device Relocation Information:
Device Reloc Device ID
c0d0 Sí id1,cmdk@AVMware_Virtual_IDE_Hard_Drive=00000000000000000001

bash-3.00# metastat -t hspool01
hspool01: 2 hot spares
Dispositivo Estado Longit Reubic
d63 Disponible 204800 blocksNo Wed Jul 18 10:51:02 2007
d64 Disponible 204800 blocksNo Wed Jul 18 10:51:02 2007

Device Relocation Information:
Device Reloc Device ID
c0d0 Sí id1,cmdk@AVMware_Virtual_IDE_Hard_Drive=00000000000000000001

2.- Con la misma disposicion de las "soft particions" del punto anterior, generamos un pool ZFS denominado mypool resultante del Stripe creado entre el metadispositivo d63 y d64, asi:

bash-3.00# zpool create mypool /dev/md/dsk/d63 /dev/md/dsk/d64
bash-3.00# zpool status -v
conjunto: mypool
estado: ONLINE
limpiar: no se ha solicitado ninguna
config:

NAME STATE READ WRITE CKSUM
mypool ONLINE 0 0 0
/dev/md/dsk/d63 ONLINE 0 0 0
/dev/md/dsk/d64 ONLINE 0 0 0

errores: ningún error de datosconocido

3.- Y para terminar creamos otro pool ZFS denominado mypool2, resultado del RAIDz entre los metadispositivos d65, d66, d67 y d68 utilizando como hotspare a d69 y a d70, asi:

bash-3.00# zpool create mypool2 raidz /dev/md/dsk/d65 /dev/md/dsk/d66 /dev/md/dsk/d67 /dev/md/dsk/d68 spare /dev/md/dsk/d69 /dev/md/dsk/d70
bash-3.00# zpool status -v mypool2
conjunto: mypool2
estado: ONLINE
limpiar: no se ha solicitado ninguna
config:

NAME STATE READ WRITE CKSUM
mypool2 ONLINE 0 0 0
raidz1 ONLINE 0 0 0
/dev/md/dsk/d65 ONLINE 0 0 0
/dev/md/dsk/d66 ONLINE 0 0 0
/dev/md/dsk/d67 ONLINE 0 0 0
/dev/md/dsk/d68 ONLINE 0 0 0
spares
/dev/md/dsk/d69 AVAIL
/dev/md/dsk/d70 AVAIL

errores: ningún error de datosconocido

OpenSolaris Day 2007

2007-07-16T16:26:00.003+02:00

El pasado Jueves 31 de Mayo del 2007 se celebraron en Madrid tanto el
OpenSolaris Day, como el OpenJava Day de los cuales podeis ver los siguientes documentos gráficos.

Personalmente dicho evento me permitió conocer en persona a los miembros de la comunidad que no conocía como a Alvaro Lopez Ortega, Pedro Gracia e Iban Nieto, ademas del recientemente incorporado Víctor de la Nuez.

Asistí junto con Daniel Rico y el lider de la comunidad Española David Galan, con los que he tenido el gusto de compartir buenas experiencias profesionales.

Ininicialmente Pedro Montarelo, director de Marketing de Sun Microsystems Iberica realizó la presentación del acto, junto con una introducción al proyecto OpenSparc y el impulso que esta generando en la comunidad.

También pude conocer personalmente a Jaime Cid, lider de la comunidad GlassFish, el cual participó a su vez en la mesa redonda junto con Alberto Roman (lider del proyecto OSSIM).

En fin, que fue una ocasión única por parte de Sun para apostar por el crecimiento y desarollo de las diferentes comunidades (OpenSolaris, OpenSparc, JavaHispano, GlassFish, OSSIM...) y que espero y deseo podamos repetirlo.

Ya estan disponibles para su descarga las presentaciones de cada uno de los talleres y ponencias que realizamos los miembros de la Comunidad Española:

Introduccion a Nexenta => Pedro Gracia
Solaris Containers y Resource Manager => Daniel Rico
Solaris Volume Manager y ZFS => Victor M Fernandez
Introduccion a Dtrace => Iban Nieto

es.opensolaris.org

2007-07-16T15:40:00.002+02:00

Hola a todos, como miembro activo de la Comunidad Opensolaris en España SPOSUG, ya tenemos funcionando el portal en español de OpenSolaris, patrocinado por Sun Microsystems. Desde que en la comunidad española nos pusimos manos a la obra el proceso ha sido relativamente rápido. Ahora solo nos queda ir haciendo los ajustes en estas traducciones para ir incorporando los proyectos de los diferentes grupos de usuarios que esta en marcha dentro del mismo.

Queremos que este portal no sea sólo una referencia para España, sino que también lo sea en América Latina y en cualquier sitio dónde se hable español. Una vez abierto el portal comienza la verdadera tarea de unificación de todos los esfuerzos que existen dentro del mundo de OpenSolaris que hablan español.

Ah y no olvideis la lista de distribucion (ug-sposug@opensolaris.org.): http://mail.opensolaris.org/mailman/listinfo/ug-sposug y el canal dentro del IRC (#opensolaris-es): irc://irc.freenode.net/opensolaris-es