Category Archives for "Veeam"

Nueva Web en Orbal

web-orbal

Una web llena de recursos para vosotros

web-orbal

Siempre he dicho que una imagen vale más que cien palabras, y por eso creo que lo mejor es que se vea lo que estamos haciendo.

Estamos haciendo un punto de encuentro donde un Responsable Informático pueda encontrar la mayor cantidad de recursos sobre ello, videos, white papers, e-books

Y mientras vamos populando este apartado, podéis ver nuestro nuevo site, desde donde podréis ver lo que hacemos, nuestras novedades, etc.

captura-de-pantalla-2016-09-25-a-las-18-39-52

Os esperamos pronto por www.orbal.es

Take care,

JM

 


Source: jmgriscom

Organiza tus jobs de Veeam mediante políticas

organiza-tus-jobs-mediante-veeam

El hecho de que la virtualización es una tecnología ya bastante madura en cada vez más entornos supone muchos retos. Vamos añadiendo cargas (seguramente cada vez más críticas y sensibles) a los hipervisores, nuevas máquinas, ratios de consolidación más agresivos y demás realidades que parece que induzcan la idea de que mantener el control de nuestra infraestructura tenga que ser más una cuestión de “hacer malabares”. Estos fenómenos son los que o ya afrontamos o afrontaremos en algún momento y es por ello que por ahí van las tendencias de los fabricantes cada vez apostando más por la automatización y la monitorización.

Estas realidades aplican por supuesto también a las soluciones que dependen directamente de nuestra infraestructura vSphere, como por ejemplo Veeam Backup&Replication. Antes de nada, en el caso de Veeam, lo primordial es mantener una definición de los requerimientos de cada VM en cuanto a su nivel de disponibilidad, luego veremos cómo aplicarlos y sobretodo mantenerlos de manera ágil.

Al final, lo que queremos es una manera ordenada y dinámica de proteger nuestras VMs según las condiciones específicas de cada una de ellas.

Para definir estas políticas deberemos analizar qué requerimientos tienen nuestras VMs o nuestros perfiles de VMs: tenemos que declarar los parámetros en los que basaremos nuestras políticas de Backup/Replicación.

Paso 1 – definir parámetros y valores

Un ejemplo sencillo de estos parámetros podría ser el siguiente:

  • RPO

    • ¿Cada cuanto tiempo debemos ejecutar una copia de la VM? Lo podemos medir en minutos, horas, días …
  • Ventana
    • ¿Qué intervalo tenemos para ejecutar la copia? Pierde relevancia si usamos Storage Snapshots. Expresado en franja horaria.
  • Retención
    • ¿Qué histórico de copias debemos almacenar para esa VM? Lo especificaremos en valores “absolutos”. Es decir, si quiero mantener una semana de copias y mi RPO es de 24h, tendrá un valor de 7.
  • RTO
    • Tiempo en poner la máquina en producción a partir de la declaración del desastre. En sí no es un parámetro que apliquemos al job como el RPO, pero podemos agilizarlo usando Reverse Incremental o más aún con replicas.
  • Encriptación
    • ¿Debemos encriptar los datos de esa VM?
  • OS
    • Mantener VMs de OS/Datos/Apps parecidos nos ayudará a tener mejores ratios de deduplicación.
  • ¿Backup secundario?
    • Hay que almacenar una copia de la VM en algún otro lugar.

Paso 2 – agrupar

Con  este análisis como primer paso, tendremos una descripción en términos de protección de datos de nuestras VMs, “metadatos” para cada una. Ahora nos hará falta agruparlas según valores parecidos. Fácilmente, acabaremos (siga esto entendiéndose como ejemplo) con un grupo que será “Producción – Linux” con unos valores iguales para cada parámetro en todas las VMs. Con estos grupos, tendremos una posible propuesta de organización/distribución de nuestros Jobs de Backup/Replicación.

Paso 3 – “dinamizarlo”

Sin embargo, no olvidemos que el principal ánimo de este post es hacer el trabajo (sobretodo el de mantenimiento) más sencillo. De momento, tenemos una manera ordenada de proteger a nuestras VMs según los requisitos específicos de cada una, pero no hemos hablado de cómo hacer todo este proceso dinámico o semi-automatizado.

Cuando hablamos de Jobs dinámicos en Veeam Backup & Replication, nos referimos a Jobs que como origen tienen un objeto que no es/son una VM en sí. En la definición del job, como “Source”, podemos añadir una a una cada VM que cumpla los requisitos definidos por el Job. Si tu entorno es pequeño, y sobretodo, con pocas modificaciones, es algo planteable, pero si el entorno va evolucionando (que es lo más normal), habrá que empezar a plantear otras maneras, puesto que no vamos a ir añadiendo VMs a los Jobs, sería bastante ineficiente.

En el fondo, para tener un job dinámico bastaría con crear uno solo para toda tu infraestructura que, como “Source”, incluyera todo el vCenter. De esta manera, toda máquina nueva sería incluida directamente en la copia sin necesidad de dar “un paso más” añadiéndola. Sin embargo, catalogar todas las VMs bajo la misma definición no es lo que buscamos tampoco.

Es aquí donde toman relevancia objetos de vCenter que quizás no habías tenido en cuenta antes, como son las etiquetas (o “tags”) y las carpetas. En este whitepaper, Luca Dell’Oca nos sugiere que, una vez definidos los grupos de VMs que hemos visto en el paso 2, cada grupo se mapee a un tag de vCenter y luego, creando un Job para cada grupo, añadir cada etiqueta como “source” del job. Así pues, para nuestro grupo de ejemplo “Producción – Linux”, tendremos que crear su etiqueta en vCenter, etiquetar cada VM que pertenezca a este grupo con ella, y luego crear un Job de Veeam que como Source tenga dicho tag. Además de ser un genial White Paper (recomiendo descargarlo y leerlo detenidamente sobre todo por cómo se detallan los pasos), me parece un método perfecto para entornos heterogéneos, diversificados, (muy) grandes y con muchos usuarios y permisos en vCenter. Sin embargo, quizás vea más acorde a un entorno “standard” de los que tenemos hoy en día por nuestras tierras usar las carpetas de vCenter . La razón es sencilla: al crear una VM, ya sea mediante el wizard tradicional del cliente de vSphere o incluso mediante herramientas de terceros como Chef, nos dejará (de hecho nos “obligará”) especificar en qué carpeta la ubicamos.

Esto hace que no tengamos que dar ese “paso más” de luego ir y etiquetar la VM. Luca habla de maneras muy válidas mediante scripting por ejemplo de automatizar el proceso de etiquetar, pero quizás es demasiado complejo si ya nos sirven las carpetas.

La idea es que no queden máquinas virtuales fuera de copia. Si usamos carpetas, nos aseguramos que siempre nos pregunte en qué carpeta ponemos la VM, pero cabe la posibilidad de que la VM caiga en la carpeta “Discovered Virtual Machines” o en la matriz del Datacenter. Para mitigar este problema, podemos por ejemplo ejectuar un pequeño script que cada dia revise que no queden VMs en carpetas que no estén incluidas en ningún job.


Source: jmgriscom

El futuro de La Cloud

Leo  “Por ello un 41% de las compañías españolas ya utiliza la nube de alguna forma, según un estudio llevado a cabo por IDC. Esta cifra es muy superior al 15% de 2011 y aumentará hasta alcanzar el 52% en 2014, según sus previsiones

Había quien se las creía muy felices con este crecimiento “imparable”, pero claro sólo Jano, el Dios de pasado y del futuro es el que tiene “los datos” en el bolsillo…

No hay duda que la crisis ha vuelto a las empresas recelosas, defensivas, y “mirando hacia adentro” y más sobre su core business que no sobre procesos como los de TI. Que sí, que lo entienden y les gusta lo del “pago por uso”, pero lo miraremos más adelante.

Personalmente no creo que todo sea eso. Creo que falta confianza y una nueva cultura.

Sin duda que AWS, Microsoft y Google son los “chicos grandes” del patio. Pero tuvieron su parte visionaria y “su desierto del Sahara” para llegar a donde están. Vamos a decir que Microsoft supo darse cuenta del cambio del viento y hizo un viraje importante apostando por Azure.

Vuelvo a ver el informe IDC de este año y aunque más comedido, sigue haciendo “push” hacia “La Cloud”. 

Mi punto de vista.

El TI que hay ahora en Cloud, según mi visión, nace de 3 orígenes:

  • La TI de La Cloud. En este grupo pondríamos toda aquella infraestructura que “como va a dar servicio a La Cloud, ¿dónde la vamos a poner si no?”
  • La TI que nació en La Cloud. Generalmente son empresa muy nuevas, que han tenido un CIO visionario y ha pensado ¿Por qué no nacemos con la TI en Cloud?
  • Las grandes empresas, que ya tienen subcontratada la TI y la tienen de Cloud.

El resto pues está en ello. Mirando al de al lado, a ver que ha hecho, leyendo si ha pasado esto o aquello en tal CPD…

Voy a hacer un par de preguntas para demostrarlo. Cuantos CIOs conocen la calificación de los CPD según TIER y cuando conocen las 5 claves para considerar que un servicio Cloud?. Los que consiguen contestar correctamente las dos preguntas son aquellos que se han planteado alguna vez mover su TI a un CPD o a La Cloud!

He sido CIO de una aseguradora durante 10 años y los entiendo perfectamente (me gustó un artículo hace mucho tiempo ¿Porqué los CIOs no confían en las montañas rusas? ) y el problema es siempre el mismo.

Como decía el primer punto es la falta de confianza. ¡Pero es que no hay que poner todos los huevos en el mismo cesto! ¿ y como lo vamos a hacer?  Pues poco a poco y sin equivocarnos…..

Particularmente creo que hay varios “approaches” al tema. En primer lugar, haga un diseño de todo su TI, incluyendo el “on-premises” y el “off-premises”, con eso Vd tendrá la visión de su Cloud Híbrida. Así sin darse cuenta Vd. verá que dispone de un “pool” de recursos inside y otro offside.

Momento muy bueno para plantearse ¿Por qué no hacemos las copias aquí en local y un “copy job” en off-site?  ¡Un primer paso para disponer de una Cloud Híbrida!

el futuro de la cloudEsto nos podría conllevar a “Si tengo los datos allí, los puedo levantar en un DR con cierta facilidad, no?”

En un momento de “pico” de trabajo, Vd puede alquilar y aprovisionar infraestructura en remoto para, por ejemplo, tener desarrollo en la Cloud, o bien convertir todo en un DRaaS, enlazando la copia con la recuperación en una plataforma remota.

La última estrategia que he visto es quedando el hardware “local” con ciertos años, contratar los servicios generales en cloud, siendo los servicios locales que son los de respaldo (pero este caso es rara avis…. )


Por ello entiendo que el modelo que se debe plantear es un movimiento “smooth”, donde además el modelo permita ir paso adelante, paso atrás (Clouds Híbridas!)

Sé que varios de Vdes. están esperando por la cultura….  Verán, allá por 1987 yo era un técnico que mi función era, dentro de una gran industria química, forma y “vender” el uso de los PCs bajo es escepticismo de mis compañeros del IBM 4381 que creían que esos “ordenadores” eran simples juguetes. Lo mismo pasaba en los departamentos. ¡Había 1 ordenador y una impresora por departamento! Hasta que llegó, y llegó la cultura del PC y yo iba arriba y abajo instalando PCs ¡1 por mesa! quien lo hubiera  imaginado nunca!!!

Y esta es mi conclusión. Sí señores, la crisis ha ahogado mucho a la Cloud, pero no ha habido programas y estrategias de atraer los servicios de TI de una forma “gradual” hacia la Cloud. Cuando llegue la cultura de Cloud, recuerden mis palabras.

Take care,

Source: jmgriscom