Entradas con la etiqueta ‘cloud computing’

Servicios cloud de recuperación ante desastres (DR)

Tradicionalmente las empresas se han fijado en los servicios de copias de seguridad y almacenamiento que ofrece la nube, pero últimamente se están fijando en los servicios de recuperación ante desastres (DR). Los proveedores cloud pueden ofrecer servicios DR a sus clientes en su infraestructura como alternativa a la necesidad de construir un sitio de replicación entero.

Pero hechos como la caída que sufrió recientemente Amazon Web Services está haciendo que muchas empresas dejen de considerar como sinómimos a los conceptos continuidad de negocio y cloud.

En un artículo anterior ya hablamos de los desafíos y oportunidades a los que los proveedores cloud deben enfrentarse. A pesar de su redundancia, la nube está basada en equipamiento físico (que es probable que pueda fallar), por lo tanto los proveedores cloud deben disponer de un plan DR (Disaster Recovery) que se active en caso de caídas y permita continuar con el servicio. Los proveedores deben probar que sus servicios de recuperación ante desastres son fiables. De este modo, si construyen servicios accesibles y elásticos (en lo que se refiere a capacidad de recuperación)y respaldados por fuertes acuerdos de nivel de servicio (SLA), pueden obtener nuevos clientes.

En un servicio de recuperación ante desastres, los clientes finales necesitan un SLA que les garantice que, en caso de desastre, su proveedor puede hacer que el servicio y los datos sean accesibles en un determinado periodo de tiempo.

En este sentido, están empezando a surgir servicios de recuperación ante desastres en la nube (Disaster Recovery as a Service – DRaaS) elaborados por fabricantes relacionados con productos para cloud computing y IaaS. Un ejemplo es el ecosistema anunciado recientemente por Zerto, un fabricante de software de productos de virtualización, también conocido como Zerto Cloud Disaster Recovery Ecosystem (ZCE). Este ecosistema se basa en un programa de partnership en el cual los proveedores cloud pueden establecer de forma fiable servicios DR en la nube.

El programa ZCE permite a los proveedores cloud replicar sus datos a nivel de hypervisor, a diferencia de otros servicios de replicación de datos que se basan en arquitectura de almacenamiento. De esta forma, la capa de replicación es agnóstica del tipo y tecnología de almacenamiento utilizado. Uno de los principales requerimientos que existían hasta ahora es que los clientes tuvieran el mismo tipo de almacenamiento que su proveedor cloud DR, lo cual hacía incrementar los costes de implantación.

Al replicar máquinas virtuales a nivel de hypervisor, el servicio es mucho más escalable, flexible y en línea con el paradigma de la tecnología cloud.

Share

Pasos para construir nuestra propia nube privada

Nos hemos encontrado con un documento elaborado por Eucalyptus, uno de los principales fabricantes de software IaaS para crear clouds privadas, en el cual se indican los pasos que debemos seguir para construir nuestra propia nube privada. A continuación os los resumimos:

 

Paso 1: Adoptar una tecnología de virtualización

El cloud computing utiliza como tecnología base a la virtualización. Las máquinas virtuales se ejecutan bajo una capa de software llamado hypervisor. Ésta permite al administrador disponer de servicios y herramientas para gestionar sus máquinas virtuales como si fueran procesos de software independientes.

El primer paso para implementar nuestra propia cloud privada es elegir el hypervisor sobre el cual correrán nuestras máquinas virtuales cloud. Entre los aspectos a considerar nos encontramos con: precio, características, conocimiento de la plataforma, nivel de estabilidad y fiabilidad.

 

Paso 2: Requerimientos de computación, memoria, rendimiento y almacenamiento

Los principales desafíos a la hora de construir nuestras aplicaciones cloud son aquellos relacionado con los conceptos de escalabilidad y recursos dinámicos, los cuales están implicitamente asociados al modelo. Normalmente, los recursos de computación y red cambien poco en la versión cloud de una aplicación, pero la abstracción cloud del almacenamiento puede no ser trivial.

Las nubes deben ser capaces de escalar en número de recursos y en ratio de transacciones de usuario concurrentes. Para ello, es necesario implementar abstracciones del almacenamiento diferentes a los ficheros de un entorno tradicional. Por lo tanto, a la hora de portar aplicaciones a  un entorno cloud, necesitamos conocer cómo funciona esta abstracción.

Además deberemos asegurarno que las aplicaciones tengan el mismo rendimiento y niveles de robustez ante la presencia de actividad dinámica en la nube.

 

Paso 3: Asesoría en el diseño de máquinas virtuales

Es habitual que los administradores de clouds privadas suministren un conjunto base inicial de máquinas virtuales preconfiguradas de las cuales los usuarios pueden elegir para utilizar y ejecutar sus aplicaciones. Estas máquinas virtuales necesitan ser catalogadas de un modo que permita a los usuarios conocer su utilización.

Conforme la nube va madurando, los usuarios pueden querer crear sus propias máquinas virtuales desde cero o modificando las imágenes ya definidas. Para adaptarse a estos requerimientos, a veces es necesario disponer de expertos en configuración de sistemas operativos que nos permitan personalizar nuestras máquinas virtuales.

 

Paso 4: Implementación de políticas de pago por uso de recursos

Nos podemos encontrar con situaciones en las cuales un usuario adquiera únicamente las máquinas virtuales que quiere utilizar pero no las liberen cuando ya no las necesiten. O peor aún, en caso de un déficit de recursos disponibles, pueden acaparar recursos que se les han asignado.

En una cloud pública, los usuarios pagan una cuota por recursos utilizados durante un determinado periodo de tiempo. En una cloud privada, se debería implementar una política similar para incentivar el uso responsable de recursos. Adoptar medidas como la suspensión de servicios en caso de sobrepasar una determinada cuota puede no ser adecuada. Es más recomendable una política que informe sobre esa sobreutilización y disuada el abuso de recursos por parte del usuario.

 

Paso 5: Crear un plan de diseño y desarrollo de nuestra cloud privada

Los principales elementos de diseño de la arquitectura de nuestra nube incluyen: almacenamiento (topología DAS o SAN), la topología en lo que respecta a conectividad de red, interacción entre máquinas virtuales, políticas de seguridad y la gestion del tráfico entre máquinas virtuales.

Como en todas las infraestructuras de centro de datos, un plan de diseño y desarrollo es necesario para lograr la máxima eficiencia en un entorno en producción.

Share

Cambios en la estrategia de negocio de VMware

A principios de mes os comentábamos movimientos en el líder del sector de virtualización, VMware. Éste adquiría la compañía DynamicOps que permite convertir a su sistema vCloud en multi-hypervisor.

Los movimientos dentro de la compañía americana parece que no acaban ahí. La semana pasada VMware confirmó que el actual CEO de VMware (Paul Maritz) será  sustituido en Septiembre por el presidente de la división Information Infrastructure Products de EMC, Pat Gelsinger.

Según los expertos, detrás de este movimiento puede estar la creación de una nueva empresa centrada en productos cloud y que le permita competir en el mercado del cloud computing. Esta nueva entidad podría supervisar su plataforma de aplicaciones cloud (PaaS) Cloud Foundry. El hecho de crear una nueva empresa tiene sentido, ya que permite separar su principal línea de negocio (centrada en virtualización y productos para crear sistemas IaaS) de las soluciones PaaS. De este modo se evitarán conflictos entre la propia infraestructura cloud VMware y sus posibles clientes IaaS. La compra de DynamicsOps añade más sentido a los movimientos de VMware. No tiene sentido intentar expandir tu línea de negocio PaaS si tu producto no puede ejecutarse sobre cualquier hypervisor.

VMware se encuentra en un momento decisivo: o se expande en nuevos mercados relacionados con el cloud computing o se mantiene únicamente como un fabricante de productos de virtualización. Es cierto que sus productos de virtualización son la principal fuente de ingresos de la compañía, en el segundo trimestre de 2012 incrementaron los ingresos en un 22% (record de ingresos con 1.123 billones de dólares). Pero conforme el cloud computing crece en popularidad, VMware no puede quedarse dormido y convertir su producto vaca en perro.

Share

Ejemplos de modelo de negocio Cloud Federation

En un artículo anterior sobre tendencias para 2012 en el mercado de proveedores cloud ya incluíamos el Cloud Federation. Este término hace referencia al movimiento que están realizando los proveedores cloud en establecer alianzas entre ellos con el objetivo de compartir recursos. El objetivo es poder ofrecer un servicio eficiente y más escalable y avanzado independientemente de la localización del cliente, ya que los posibles compradores de servicios cloud son a menudo empresas globales.

Una federación cloud permite a los proveedores unir fuerzas para mejorar sus perspectivas de crecimiento y sostenibilidad, permitiéndoles competir contra los gigantes de la industria como Amazon o Google. Aunque la tecnología y el mercado de cloud federation todavía está comenzando, su rápido desarrollo significa que los proveedores cloud deben estar atentos para identificar si tiene sentido o cómo unirse a una cloud federation. Los expertos opinan que la principal clave del éxito de una cloud federation es el modelo de negocio que elijamos, no los estándares o tecnologías.

Formas de construir una cloud federation

A continuación os vamos a mostrar tres empresas posicionadas en el mercado de cloud federadas que muestran los potenciales beneficios o desventajas del modelo. Cada una de las empresas ofrecen distintos modelos de negocio.  A pesar de sus diferencias, las tres comparten características. Por ejemplo, cada una de ellas ha creado su plataforma de software propietaria a través de la cual los proveedores de servicio pueden implementar servicios cloud.

1.- SpotCloud

SpotCloud utiliza una cloud federation para unir proveedores y usuarios en una plataforma de recursos IaaS. SpotCloud funciona como un broker de servicios IaaS, permitiendo a proveedores de este tipo de servicios “federar” sus recursos y vender sus capacidades de computación no utilizadas a usuarios que estñen buscando proveedores cloud locales.

2.- OnApp

OnApp permite a distintos proveedores cloud unir sus recursos y utilizar las capacidades no utilizadas (en este caso de ancho de banda) para ofrecer servicios de Content Delivery Network (CDN) globales.

3.- Tier 3

Tier 3 permite a los proveedores asociados a su federación expandir su servicio en distintas regiones del mundo sin tener que comprar o alquilar nuevo espacio en un centro de datos. Tier 3 interconecta nubes entre sí a través de un software propietario orientado a proveedores de servicios gestionados (MSPs) y proveedores cloud pequeños. Tier3 enlaza distintos nodos de tal modo que un proveedor asociado puede utilizar recursos de un nodo externo.

Share

5 errores comunes cuando contratamos servicios cloud

Conforme los profesionales IT ganan en conocimiento acerca del cloud computing, empiezan a hacerse preguntas acerca de qué funcionalidades les puede aportar este tipo de servicios. Utilizar servicios en la nube puede convertirse en una decisión estratégica.

El hecho de incorporar servicios cloud en la infraestructura informática de una empresa conlleva tomar ciertas decisiones. Una elección errónea puede afectar al funcionamiento de la empresa. El objetivo de hoy es presentar 5 errores comunes en los que suelen caer las empresas a la hora de tener presencia en la nube.

1.- No estimar correctamente las necesidades de red

El principal objetivo de mover cargas de trabajo informáticas a la nube es eliminar las restricciones de procesador y memoria que tenemos en los servidores y/o PCs de nuestra red.

Conforme aumentan los recursos de procesador y memoria hasta una capacidad “infinita”, lo hace a costa de nuestra red. Planificar el traslado a la nube requiere especial atención a nuestros recursos de red. Si no es suficiente o existe una alta latencia con el proveedor cloud, el rendimiento de nuestras aplicaciones cloud será pobre afectando a la productividad de nuestros empleados.

2.- No elegir el proveedor cloud adecuado

Aquellas empresas que están considerando contratar servicios cloud necesitan determinar qué servicios van a mover y a qué proveedor cloud. Este proceso puede ser complejo.

En primer lugar calcularemos qué actividades (como protección de datos, gestión de sistemas, almacenamiento de documentos, etc) son complejas o costosas de administrar en nuestra infraestructura. A continuación crearemos una proposición de valor para obtener esos servicios de un proveedor cloud y por último decidiremos su contratación si los costes asociados se adecúan a nuestro presupuesto.

Los errores suelen aparecer cuando los responsables IT contratan servicios cloud a un proveedor no adecuado. Por lo tanto, durante el proceso de planificación tenemos que estar seguros de haber investigado todas las opciones y proveedores posibles haciéndonos preguntas como: ¿El software open source se adapta a las necesidades de nuestra empresa? ¿Un determinado proveedor cloud ofrece el servicio o soporte que necesitamos? ¿Tenemos personal propio para administrar cualquier tipo de servicio no controlado por el proveedor cloud?

3.- No determinar las cargas de trabajo adecuadas

Además de elegir el proveedor cloud adecuado, debemos determinar las cargas de trabajo que moveremos a la nube. A veces es posible que contratemos servicios que no son adecuados para ejecutarse en la nube.

Deberemos tener en cuenta cómo afectará a los usuarios finales mover ciertas cargas de trabajo a un proveedor cloud. Podemos caer en el error de pensar que facilitará nuestra administración pero a costa de afectar la eficiencia de los usuarios.

Las cargas de trabajo adecuadas para la nube serán aquellas que beneficien a los administradores y a la experiencia del usuario final, y además ofrezcan el mejor ROI a la empresa.

4.- No considerar posibles pérdidas de servicio del proveedor

El principal argumento de los profesionales IT contra la adopción de servicios cloud es la posibilidad de pérdidas de servicio (de hecho son conocidas ciertas noticias acerca de caídas de servicio de proveedores cloud).

Cuando se adoptan servicios cloud, se deben asumir ciertos riesgos. Aún así no debes asumir que tu proveedor cloud es infalible, ten siempre un plan de contingencia como tener múltiples proveedores cloud o utilizar tecnologías de alta disponibilidad.

5.- Ignorar al cliente

Un error final en el que caen las empresas es cuando su presencia en la nube se centra en la relación entre un servicio IT y su aplicación cliente. Dicho cliente puede distribuir el servicio a los usuarios mediante varios mecanismos: escritorios virtuales (VDI), virtualización de aplicaciones, streaming, etc.

Las empresas deben ajustar el tamaño de su mecanismo cliente basándose en las necesidades del usuario final y en la conexión entre el cliente y el proveedor cloud. Aplicaciones que funcionan perfectamente en tu infraestructura local con un determinado software cliente, pueden no funcionar igual de bien en la nube.

Share

Bienvenido a Virtualizamos

Virtualizamos es un proyecto de la empresa nerion que nace con el objetivo de convertirse en un portal de referencia en el mundo de la virtualización y el cloud computing.
Suscripción a Virtualizamos
Entradas antiguas por mes
Twitter
nerion - Registro Dominios, Hosting y Housing Profesional