viernes, 17 de junio de 2011

Replicación entre almacenamientos San StarWind y batería de pruebas

Hola.

Siguiendo al post inmediantemente anterior a este, vamos a ver cómo se comporta nuestro entorno de clúster al cual le estamos sirviendo una lun replicada entre dos cabinas de forma síncrona.

Lo primero es hacer llegar esta lun a los servidores, para ello no tenemos más que comprobar que la primera replicación se ha realizado corréctamente y atacar por iscsi a las dos cabinas desde nuestros nodos, eh aquí las capturas:

Comprobación de replicación:

 sw25 sw26

Después crearemos las conexiones desde los hosts:

sw29 (en mi caso uno se ataca a él mismo ¿?, si es que soy así de pobre :))

Una vez creadas las conexiones, veremos las luns y las activaremos:

sw27 sw28

Activaremos el disco, formatearemos, bla, bla, bla.

Crearemos un clúster y a ese detalle no voy a entrar ¡cuando tenéis material como este!:

http://blogs.technet.com/b/davidcervigon/archive/2010/03/08/montando-laboratorios-pruebas-de-concepto-y-pilotos-de-virtualizaci-n-instalaci-n-de-los-hosts-de-hyper-v-y-el-cluster.aspx

Una vez montado el clúster, veamos como se comporta si le quitamos las conexiones y simulamos la caida de la cabina:

Si quitamos la conexión con la cabina principal, el disco sigue sirviendose corréctamente:

sw31

Activamos la conexión y esperamos que la sincronización replique :

swprueba30

Desconectamos la conexión con la cabina de respaldo y el disco sigue también, sirviéndose perféctamente:

 swprueba31

Ahora comprobamos que el clúster está correcto y que una máquina virtual que había creado, sigue ahí:

swprueba33

Y aunque en formato redirigido, que luego cambia, parece que aguanta :).

Nuestra Vm está:

swprueba32

Bueno y llegado a este punto, parece que tenemos un entorno en producción y otro de backup y al utilizar un virtualizador, podemos llegar a montar escenarios en que las dos cabinas son de diferente fabricante o diferente generación.

 

Saludos.

miércoles, 8 de junio de 2011

Clúster con replicación entre almacenamientos parte 1 – El almacenamiento

 

Hola.

En este primera entrada, voy a empezar la creación de un clúster en el que alojaremos servicios de máquinas virtuales con Hyper-V R2. Lo que hará especial a nuestro clúster es la replicación entre almacenamientos san que vamos a lograr previamente y cómo vamos a poder realizar una batería de pruebas, llegando a dejar caer una de las cabinas que conforman nuestro escenario, garantizando así una mayor disponibilidad de servicios.

Como no, debemos empezar por la puesta en marcha de nuestro almacenamiento, yo voy a utilizar Starwind, el cual en su versión 5.0 nos ofrece la creación de luns replicadas de forma síncrona entre dos cabinas distantes.

Como sabéis, Starwind es un target iscsi, el cual nos convierte cualquier servidor con sistema operativo Ws2003 o posterior en un almacenamiento San, en un principio la primera impresión es pensar que es un riesgo y que no es una san clásica, pero cuando entramos a su página web y vemos sus clientes, si ya conocéis el mundo del “oemizado”, nos lleva a pensar que más de una cabina san al final no es más que un hardware muy fiable y un chasis con mucha capacidad de discos, combinado con un sistema operativo linux con target iscsi y/o fibra , Windows Storage server o una combinación de Windows Server + Starwind entre otros.

El almacenamiento lo montaré sobre dos servidores, los cuales tendrán una comunicación de 100mbps y como voy falto de recursos :), una cabina estará sobre Windows 2003 Server y la otra contará con Windows Server 2008 R2.

Paso a paso:

Todo comienza con la instalación del producto, a continuación os paso los pantallazos de una de las instalaciones, pero por supuesto esta instalación hay que repetirla en los dos servidores.

sw1 sw2
sw3 sw4
sw5 sw6
sw7 sw8
sw9 sw10
sw11 sw12Por defecto: usuario: root - contraseña: starwind

 

Una vez tenemos instaladas las dos cabinas, debemos crear una lun en modo HA, los pantallazo son estos:

 

sw13

sw14

sw15

sw16

Esta pantalla anterior dice mucho, como veis no solo podemos crear luns en HA, si no cosas tan chulas como luns en Raid1 con una sola cabina y mucho más.

 

sw17
Momento de conectarse a la segunda cabina
sw18
sw19

sw20

Configuración de ip propia de cada servidor dedicada para la replicación, en mi caso de hecho será una tarjeta compartida y veréis como funciona.

sw21sw22

Aunque yo he preferido rizar el rizo y decir que no quiero cacheado, es conveniente dotar a un entorno en producción de una buena caché para almcenar información cuando hay una desconexión entre cabinas o cuando el ancho de banda de la red es menor del necesitado.

sw24sw26

    

Os dejo el data sheet del producto HA:

http://www.starwindsoftware.com/starwind-enterprise-ha-data-sheet

Bueno, ahora solo nos quedaría montar un clúster y probarlo, eso lo veremos más adelante.

Un saludo.

miércoles, 1 de junio de 2011

Colaboración gira de virtualización.

Hola.

Estos días estaremos colaborando como suele ser habitual con Microsoft en la gira que Albora va a realizar por varias ciudades, para hablarle a sus clientes sobres los productos que distribuye, relacionados con la creación de nubes privadas y virtualización.

Este es el link, de los eventos:


Webcast sobre Intune.

Hola.

Os dejo el link desde el cual, os podéis descargar el webcast que la pasada semana realizamos mi amigo Oscar Marín y yo.


Aprovechando, en ese link podéis ver todos los eventos de la comunidad SecondNug, donde se está cocinando algo gordo para los ItPros pero que por el momento no podemos contar :).


P.d.: A ver si saco tiempo y os cuelgo unas entadas chulas sobre la puesta en marcha de una replicación entre cabinas y la creación de un clúster, pero esto de la crisis provoca que trabajemos el triple para ganar la mitad :(.

jueves, 19 de mayo de 2011

Van listos.

 

Hola.

Hace tiempo que no utilizo el blog como altavoz, bien es cierto que sé que muchos de los que pasáis por aquí, sois o bien partners o bien clientes finales, provenientes muchos de los diversos “saraos” en los que me dejo liar.

Aunque tanto partners como clientes finales, estamos en dos extremos distantes, al final “sufrimos” y afrontamos juntos los cambios del sector, por un lado los clientes finales demandáis nuevos productos que llegan para cubrir ciertas necesidades y por otro, nosotros, como proveedores de confianza, os ofrecemos esos productos, en teoría, añadiendo el valor de haberlo estudiado y experimentado previo al inicio de su aparición.

Después de recapacitar un poco sobre la relación que tenemos dos grandes jugadores que engloban gran parte de los profesionales del sector, intento encajarlo en el modelo que se está diseñando actualmente y que por un lado me asusta, pero por otro y más aún después de las experiencias vividas esta semana y que ahora os contaré, me alegra al comprobar que va a tener que ser rediseñado ya que así de pronto, tal y como está diseñado, no va a funcionar.

Primera experiencia, un cliente muestra interés por adquirir los servicios de filtrado anti-spam en la nube que ofrece uno de los grandes jugadores en internet, el precio de este filtrado por buzón es de 8€/año. El cliente muestra interés al fabricante y presenta como intermediario a Zerkana como proveedor de confianza, pues bien, una vez iniciados los contactos, resulta que 8€ por buzón al año, dan para que todo el territorio nacional, lo atienda una persona desde Irlanda y no solo es el mal soporte mi sorpresa, si no que no han previsto la figura del partner, por lo que no hay margen previsto, en definitiva, primer servicio que los partners no vamos a distribuir y ya veremos si esa persona consigue saltarnos y vender a nuestros clientes.

Segunda experiencia, empresa muy conocida la cual suele desarrollar software genial que añade valor a entornos Microsoft. Los servicios ofrecidos desde su web se venden con pago mensual y la compra es a través de tarjeta de crédito, una vez nuestro cliente muestra interés por ese software, Zerkana se pone en contacto con el fabricante y, primero, no hay otra forma de pago que no sea mensual (algo que en una compañía mediana como que no vale), segundo, no hay otra forma de pago que no sea a través de tarjeta de crédito (segunda pega en cualquier empresa mediana o grande), ¿solución?, Zerkana ha de pagar mensualmente y esta ha de facturar anualmente al cliente, ok, lo hacemos así, peeero, no está previsto que los servicios por internet se vendan a través del canal y no hay descuento a partner, por lo que el fabricante me cuenta el cuento de que yo lo ofrezco por X, pero tu véndelo por X+10€, a lo que yo contesto, muy bien, pero vas a vender tantos productos como seas capaz de ofrecer por web, porque yo no voy a hablar de tu producto allá donde vaya.

Por lo visto nos quieren saltar y eso es algo que ya intentaron empresas provenientes de USA, sin saber que al menos por aquí, el que se sienta en la mesa del informático, cio o gerente somos nosotros y ya nos cuesta sudores que compren, como para pensar que es viable que el cliente voluntariamente entre a una web, meta su tarjeta y compre, van listos, yo sé de algunos que ya han tenido que montar su red de partners, después de no pocas cabezas cortadas por culpa de unos cuantos años de resultados en negativo.

Saludos.