Opiniones, noticias y artículos de nuestro equipo

Entradas etiquetadas como ‘how-to’

Una guía de SAP en Amazon Web Services

aws-sap
Una de las consultas habituales que nos hacen nuestros clientes es qué relación hay en la actualidad entre SAP y AWS y si ya es posible instalar SAP en instancias de AWS o si existe alguna modalidad de subscripción.

Desde 2008, año en que SAP se convirtió en cliente de AWS, la relación de partnership tecnológico entre ambas compañías no ha dejado de incrementarse y en nuestros días AWS ya es “SAP Global Cloud Services” y “SAP Global Technology Partner”.

A fecha de hoy ya existe un conjunto de soluciones SAP certificadas para entornos de producción (con ciertas limitaciones) que pueden ser suministradas desde AWS:

  • SAP Business Suite, el SAP clásico.
  • SAP Business All-in-One, la solución pre-configurada de SAP basada en SAP Business Suite.
  • SAP Rapid Deployment Solutions, SAP Business Suite preconfigurado y con servicio de Hosting.
  • SAP BusinessObjects BI Solutions, DataWareHouse.
  • SAP Afaria, la parte de movilidad de SAP y acceso al transaccional y al BI desde dispositivos móviles.
  • SAP HANA One, la nueva arquitectura de SAP, evolución de NetWeaver, que incluye base de datos “in-memory”.

Y en proceso de certificación:

  • SAP Business One, la solución SME de SAP no basada en SAP Business Suite.
  • Sybase Unwired Platform, el PaaS de SAP para desarrollo entorno móvil.

Sistemas Operativos y base de datos certificados

Ni todos los sistemas operativos ni todas las bases de datos que funcionan en R3 de SAP están certificados para AWS.

Quizás la limitación más evidente a la fecha, para actuales clientes SAP que exploren la posibilidad de moverse hacia AWS, es que Oracle DB no está certificada aun para entornos de producción (a fecha de hoy).

En este ámbito, los sistemas operativos certificados son:

  • SUSE
  • Red Hat
  • Microsoft Windows Server 2008

Y las bases de datos certificadas son:

  • IBM DB2
  • SAP MaxDB
  • Microsoft SQL Server 2008
  • Sybase

Licencias

SAP habilita el BYOL (Bring-Your-Own-License) para aquellos clientes que quieran probar/migrar sus soluciones SAP a AWS.

La lógica, en cualquier caso, aconsejaría negociar, a ser posible, de forma particular estas condiciones, ya sea con la misma SAP o con el partner de turno.

Otros tipos de licencias disponibles incluyen SAP HANA One Business Edition a 0,99$/hora (consultar disponibilidad por zona geográfica) y BI-BO para 5 usuarios.

De forma adicional los desarrolladores disponen licencias Trial/Developer para SAP Afaria, SAP Process Orchestration, Sybase Unwired Platform y SAP HANA One.

Algunos partners globales y locales de SAP ya ofrecen soluciones personalizadas basadas de forma parcial o total en AWS.

Tipos de Instancias EC2 y precios

Los requerimientos de tipo de instancia EC2 para correr SAP en entorno productivo, según lo que el mismo Amazon ha realizado en los benchmarks de cálculo de SAPS, parten de instancias de alto consumo de recursos, y no de las básicas. Éstas últimas pueden utilizarse en entornos de test o desarrollo.

Los cálculos anteriores empiezan con instancias de la familia “High-Mem” y, en concreto, las de “Double Extra Large” y saltan a las de la familia “Cluster Compute”. Ambas dan valores de SAPs óptimos para el benchmark, pero son de las instancias EC2 más caras.

El pasado 13 de Febrero de 2013 AWS hizo el ejercicio de cálculo para el coste mensual de 1 instancia EC2 “on-demand” para correr SAP. La instancia del cálculo era una M1 “Extra Large” activa de lunes a viernes de 8 de la mañana a 8 de la tarde, con 200 GB de almacenamiento permanente en volumen EBS y de 300 GB de almacenamiento para Backups en S3. Todo por 198 $.

Si bien los precios de Amazon tienen por costumbre bajar, según lo visto en los últimos tiempos, hay que tener en cuenta en el cálculo anterior dos factores que AWS no incluyó y que condicionan el precio al alza, en caso de realizar los cálculos reales desde Europa.

  • Restringir el tiempo de actividad de una instancia para SAP de 8 de la mañana a 8 de la tarde puede no ser realista para muchos SAP transaccionales con operaciones continuas programadas fuera de horas de oficina.
  • Los mencionados precios están calculados para la región “US-East” (más económicos que para Europa – Irlanda) y no incluyen el recomendable “Business Support” que incrementaría en unos 100 $ el precio mensual, además han incorporado el pequeño descuento que se aplica para nuevos clientes el primer año con el “Free-Tier” que ofrece AWS.

Más información

  1. Aquí puedes acceder a la calculadora que AWS ha utilizado para realizar el mencionado cálculo del artículo.
  2. Listado de recursos SAP dentro de la web de AWS.
  3. Durante el pasado SAPPHIRE NOW USA realizado en Julio de 2012, SAP registró un capítulo de “Inside The Ecosystem”, en el que desde un punto de vista más de negocio se habló de SAP en AWS.

Sobre el autor

Tomàs Manzanares - Sales Consultant at CAPSiDE

Tomàs Manzanares es Sales Consultant en CAPSiDE, consultor certificado por SAP, Blogger/Founder/Media Producer en MossegaLaPoma.cat y formador en el post-grado en Community Management y comunicación digital de la UPC School of Professional & Executive Development.

Categoría:

Amazon, AWS, Cloud

Etiquetado con:

Ejecutando un listado de comandos: “The ViM Way”

Esta receta aplica a un esecenario en el que hemos recogido en un fichero una serie de comandos que queremos ejecutar.

Podemos ejecutarlos mediante bash, pero en este caso queremos revisar la salida de cada comando. También es posible que falle alguno de ellos, y queremos poder volver a ejecutarlo, o realizar pruebas más tarde.

En este ejemplo, tenemos una serie de comandos de aptitude para downgradear versiones de algunos paquetes que quizá hayamos instalado por error.

Un extracto de este fichero sería algo parecido a esto:

aptitude install libcap2=2.11-2
aptitude install libcomerr2=1.41.3-1
aptitude install libconsole=1:0.2.3dbs-65.1
aptitude install libexpat1=2.0.1-4+lenny3
aptitude install libfontconfig1=2.6.0-3
aptitude install libgdbm3=1.8.3-3
aptitude install libgpg-error0=1.4-2
aptitude install libgpm2=1.20.4-3.1

Mediante las características de ViM, podemos facilitar y semi-automatizar la tarea de ejecución, teniendo siempre control de los resultados de cada comando y la opción de actuar si se da el caso.

¿Qué vamos a utilizar?

  • Creación y edición de macros
  • Ejecución de comandos desde dentro del mismo editor
  • El mantra act, repeat, reverse [1]

Preparación

Lo que vamos a hacer es grabar una macro que consiste en eliminar la línea donde está posicionado el cursor, y utilizar el registro donde se guarda dicha eliminación para ejecutar el comando.

A continuación, los comandos de ViM para preparar la macro.

Deben ejecutar desde el modo normal, y sin ningún espacio (en este caso se ha desglosado por claridad):

qq # comenzar a grabar la macro, en el registro 'q'
dd # eliminar la línea bajo el cursor. Queda guardada en el registro '0' y en el '"'
:!<C-r>0 # En modo ex, utilizar ! para ejecutar comandos, insertar el contenido del registro 0 (Control-r 0)
<backspace> # Si existe, eliminar el carácter de final de línea. Se muestra como '^M'
<CR> # Ejecutar por primera vez el comando

La ejecución podría incluír alguna interacción con el usuario (apretar Y, o <CR>, o algo similar), que queda también grabado en la macro. Al volver de la salida de ejecución volveremos a apretar ‘q’ para parar la grabación de la macro. Si hemos interactuado en la shell, habrá que eliminar las teclas correspondientes de la macro, y lo podemos hacer editando el registro ‘q’, donde ha quedado grabada.

Para eso, desde el modo normal, copiaremos el contenido de la macro en un buffer alternativo (o al final del mismo fichero), lo editaremos como si fuera un texto normal, y volveremos a guardar el contenido en el mismo registro.

G # ir al final del fichero
:put q # Desde modo ex, pegar el contenido de la macro

Deberíamos tener una línea similar a esta:

dd:!^R"<80>kb^M<contenido extra>

Simplemente eliminamos lo que no queramos que se incluya en la macro y guardamos la línea en el registro ‘q’ de nuevo (eliminándola también del fichero):

"qdd

Primera ejecución

La primera vez que la ejecutemos, lo haremos como @q (indicando el registro q, que es donde hemos grabado la macro). Realizará la ejecución, y podremos interactuar con el comando ejecutado (en este caso, aptitude). La ejecución también incluye el borrado de línea, así que automáticamente iremos vaciando el buffer con los comandos pendientes.

Si alguno de los comandos no funciona correctamente (o en el caso de aptitude hay problemas de dependencias y queremos dejar su resolución para más adelante), siempre podemos recuperar el contenido anterior de la línea (se ha guardado en los registros por defecto, el ‘0‘ y el ‘“‘ debido a la eliminación mediante ‘dd’).

Repetición de la ejecución del resto de líneas

Una vez comprobemos que la macro funciona correctamente, podemos repetirla mediante ‘@@’, que repite la última macro ejecutada (más rápido y cómodo que @q).

También se puede automatizar para que se ejecute por cada línea del fichero, pero en este caso nos interesa supervisar todas las ejecuciones.

Sobre el autor

Luis Alberto Giménez - Systems Engineer at CAPSiDE

Luis Alberto Giménez es Ingeniero Informático por la “Universitat Rovira i Virgili” y Systems Engineer en CAPSiDE. Experto en Administración de Sistemas GNU/Linux, programación de sistemas y lenguajes de scripting como Bash, Perl y PHP.

[1] “Practical Vim”, de Drew Neil

Categoría:

Consejos, Herramientas, Open Source

Etiquetado con:

Cómo crear un usuario con acceso a un “bucket” de S3 en AWS

Gracias al servicio IAM de Amazon Web Services, que permite la gestión de indentidades y accesos, podemos crear un usuario externo (con una clave de acesso y una URL propia) y otorgarle permisos para acceder a un único “bucket” de S3.

Una IAM permite una gestión más eficiente de usuarios mediante la creación de grupos.
Para este ejemplo, crearemos un único usuario directamente.

Crear un bucket en S3

iam_user_s3_1

Conéctate a la consola de AWS, accede a la sección de S3 y crea un nuevo bucket.
Toma nota del nombre y ten presente la región dónde crees el bucket por temas de latencia.

iam_user_s3_2

Dentro de la consola de AWS accede a IAM.
Antes de crear el usuario conviene crear un “alias” de acceso a la consola de AWS. Será la URL a través de la cual el usuario que crearás se conectará posteriormete.

Anota la URL del alias.

iam_user_s3_3

Ahora ya podemos crear el usuario.
Dentro de IAM clica en el apartado “Users”, “Create a new user”, y luego escribe el nombre y marca la opción de generación de credenciales.

No necesitaremos las credenciales para esta guía, pero conviene que las guardes para necesidades futuras.

iam_user_s3_4

Creamos una contraseña de acceso para nuestro usuario desde IAM, seleccionando usuario, “security credentials“.

iam_user_s3_5

Ahora anota la contraseña que, juntamente con el nombre de usuario y la URL anterior, es la información que necesitará el nuevo usuario para conectarse.

Definir los permisos

Amazon Web Services nos permite definir permisos a nivel de grupo y/o de usuario, y lo permite mediante código JSON. Además, AWS dispone de plantillas y ejemplos ya preparados que pueden servirnos de base.

Para este ejemplo selecciona el usuario y accede a “Permissions”, “Attach User Policy” y luego “Select”.

iam_user_s3_6

Dale un nombre a la política de permisos y añade el código que encontrarás a continuación:

iam_user_s3_7

Substituye NOMBREBUCKET por el nombre de tu bucket creada


{
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:ListBucket",
"s3:GetBucketLocation",
"s3:ListBucketMultipartUploads"
],
"Resource": "arn:aws:s3:::NOMBREBUCKET",
"Condition": {}
},
{
"Effect": "Allow",
"Action": [
"s3:DeleteObject",
"s3:DeleteObjectVersion",
"s3:GetObject",
"s3:GetObjectAcl",
"s3:GetObjectVersion",
"s3:GetObjectVersionAcl",
"s3:PutObject",
"s3:PutObjectAcl",
"s3:PutObjectAclVersion"
],
"Resource": "arn:aws:s3:::NOMBREBUCKET/*",
"Condition": {}
},
{
"Effect": "Allow",
"Action": "s3:ListAllMyBuckets",
"Resource": "*",
"Condition": {}
}
]
}

Los permisos dados incluyen lectura, escritura y borrado de archivos (objetos) en el “bucket”. Si sólo quieres dar permisos de lectura, suprime las líneas de color azul.

Ahora sólo debes guardar la nueva política y enviar al usuario los datos de conexión y la URL.

Sobre el autor

Tomàs Manzanares - Sales Consultant at CAPSiDE

Tomàs Manzanares es Sales Consultant en CAPSiDE, consultor certificado por SAP, Blogger/Founder/Media Producer en MossegaLaPoma.cat y formador en el post-grado en Community Management y comunicación digital de la UPC School of Professional & Executive Development.

CRÉDITOS: Esta guia se publicó originalmente en catalán en Cloud4Pro

Categoría:

Amazon, AWS, Cloud, Consejos

Etiquetado con:

¿Cómo recuperar elementos eliminados por parte del usuario en Exchange 2010?

Exchange Server 2010 dispone de un mecanismo denominado “Retención de elementos eliminados” que permite configurar los días que los correos se mantendrán en el sistema después de ser eliminados por el usuario.

Logo de Exchange Server 2010

1 · ¿Cómo configurar la retención?

El valor por defecto de este parámetro es de 14 días. Los administradores del Exchange pueden modificar este valor desde la consola de administración de Exchange.

  1. Abrir la consola de administración de Exchange Server 2010
  2. Desplegar el árbol del panel izquierdo
  3. Ir a “Configuración de la organización”
  4. Seleccionar “Buzón”
  5. En panel derecho aparecerán las bases de datos disponibles
  6. Clic con el botón derecho del ratón sobre el nombre la base de datos a la que deseamos modificar la “Retención de elementos eliminados”
  7. En el menú contextual seleccionar “Propiedades”
  8. En el formulario de las propiedades de la base de datos seleccionar la sección “Límites”
  9. Ahora puede modificar el valor del “Guardar los elementos eliminados durante (días)”
  10. Ahora solo falta aceptar las modificaciones realizadas haciendo clic sobre el botón “Aceptar”

Cuando el usuario elimina un elemento de correo este permanecerá en el sistema durante los días especificados en la “Retención de elementos eliminados” y el usuario podrá recuperarlos desde su Outlook o desde el panel del OWA.

2 · ¿Cómo restaurar elementos eliminados?

Desde Outlook

  1. Abrir Outlook
  2. Ir al buzón de correo
  3. En el “ribbon” seleccionar la sección “Carpeta”
  4. Clic en “Recuperar elementos eliminados”
  5. Aparecerá la lista de correos eliminados
  6. Seleccionar los correos que desea recuperar
  7. Clic en el botón “Recuperar elementos eliminados”

Desde OWA

  1. Iniciar sesión en OWA
  2. En el panel de la izquierda, clic sobre la carpeta de “Elementos eliminados”
  3. En el menú contextual seleccionar “Recuperar elementos eliminados”
  4. Aparecerá la lista de correos eliminados
  5. Seleccione los correos que desea recuperar
  6. Clic en el botón “Recuperar elementos eliminados”

Con este sistema solo se pueden recuperar los elementos de correo que hayan sido eliminados de forma permanente de buzón.

Si los elementos de correo no han sido eliminados permanentemente podrá encontrarlos y recuperarlos desde la carpeta “Elementos eliminados” de Outlook u OWA.

Sobre el autor

Toni Planas - Systems Engineer at CAPSiDE

Toni Planas es Ingeniero de Sistemas y forma parte del equipo de especialistas de CAPSiDE. A lo largo de su carrera profesional se ha convertido en especialista de tecnologías y soluciones de Microsoft, centrándose sobretodo en lo referente a Sistemas Operativos, Bases de Datos SQL Server y Soluciones de Correo/Mensajería.

Categoría:

Aplicaciones, Consejos

Etiquetado con:

Backups 101: ¿Qué debemos tener en cuenta? Políticas, retención, storage, restauración y herramientas.

Las copias de seguridad de las plataformas son una parte esencial de la administración de sistemas. Es, por lo tanto, un tema ampliamente estudiado y para el que se han creado multitud de herramientas. Sin embargo, realizar buenos backups sigue siendo una tarea compleja en la que interviene la definición de la política, el estudio y la elección de la(s) herramienta(s) y su implementación.

1 · Política de backups

La política de backups es la definición de los diferentes aspectos de las copias de seguridad: ¿de qué se debe hacer backup? ¿Cada cuánto se realiza la copia de seguridad? ¿Qué retención deben tener? ¿Dónde se guardan las copias? ¿Cuánto tiempo es aceptable que se pueda tardar en recuperar datos?

Obviamente, siempre es deseable tener copias diarias de todos los ficheros con una retención alta y almacén local para recuperar rápidamente, así como externo para mayor protección. Sin embargo, esto está reñido con la eficiencia y con los costes: robots de cintas, ocupación de disco, espacio físico para guardar las copias, etc. Por lo tanto, es necesario encontrar un compromiso marcando máximos en los costes, y priorizando los backups de los recursos más críticos.

Cada proyecto o plataforma tiene sus propias necesidades que es necesario definir para establecer la política. Para ello, es útil:

  • Diferenciar entre distintos entornos (preproducción, desarrollo, test, producción, etc.)
  • Determinar los costes de las posibles pérdidas de datos
  • El tiempo que se tardaría en la recuperación
  • Valorar los recursos disponibles (hardware, velocidad de la red, discos remotos, etc.)
  • Analizar qué es imprescindible copiar y qué no.

2 · Guardado y retención de backups

Un aspecto importante de seguridad a la hora de establecer una política de backups es dónde se van a guardar las copias de seguridad. Cuando se definen planes de prevención de riesgos en cuanto a tecnología se suele considerar el vaulting para mitigar los efectos de un posible incidente en el site donde se realizan los backups. Esta practica consiste en mover a otra localización periódicamente una copia completa de los datos, por ejemplo una vez al mes. Esto es habitual cuando el soporte físico es en cinta.

Esto es distinto del archiving, que consiste en mover datos antiguos que no se están utilizando a una localización distinta. Un backup es siempre una copia, mientras que el archiving consta de los datos originales que son trasladados porque no se utilizan pero no se quieren eliminar definitivamente.

Aunque hay diversas opciones de storage es interesante considerar el servicio Glacier de Amazon. Su bajo coste es una gran ventaja, pero el hecho que la restauración no esté asegurada en un tiempo concreto y que pueda tardar algunas horas lo descarta para el vaulting mientras que lo convierte en interesante candidato para archiving, donde no hay exigencias de recuperación de datos en tiempos limitados.

3 · Restauración

El objetivo final de un backup es poder restaurarlo en caso de pérdida de los datos. Por lo tanto, tener presente la restauración a la hora de definir una política de backups o escoger una herramienta es clave. Para ello, es importante haber decidido previamente (en la gestión de riesgos) los siguientes puntos:

  • RTO (Recovery Time Objective)
    Es el tiempo máximo en el que se debe alcanzar un nivel de servicio mínimo tras una caída del servicio (por ejemplo, debido a pérdida de datos) para no causar consecuencias inaceptables en el negocio.
  • RPO (Recovery Point Objective)
    Es el periodo de tiempo máximo en el que se pueden perder datos de un servicio. Si el periodo de tiempo es de 6 horas, se deben realizar backups cada menos tiempo y poder recuperar la información antes de agotar el periodo.

El tiempo de restauración de un backup en caso de pérdida de datos forma parte del tiempo en que no hay servicio, por lo que cuanto menos tarde antes se restablecerá el proceso de negocio.

4 · Herramientas

Las herramientas nos permiten implementar la política de backup. Dada la variedad de plataformas, se han creado muchísimas herramientas que actúan a diferentes niveles. Algunos tipos de backups y herramientas (hay muchos más) se muestran a continuación:

4.1 · Sincronización

Este tipo de backup permite que dos directorios en localizaciones distintas (en la misma máquina o en hosts separados) contengan los mismos ficheros. Muchas de las herramientas que permiten la sincronización se basan en rsync o en su librería.

  • Rsync: la herramienta más conocida de sincronización de ficheros, tiene muchas opciones que dan gran flexibilidad.
  • Duplicity: se basa en la librería de rsync para realizar backups de ficheros comprimidos y encriptados.
  • Unison: permite la sincronización de directorios aprovechando características de distintos sistemas y herramientas.

4.2 · Copias

El sistema básico de realizar backups es la copia de los ficheros a un espacio aparte. En este caso, se pueden utilizar herramientas de un gran rango de diversidad y complejidad.

  • fwbackups: herramienta con una interfaz simple pero con muchas opciones, permite programar backups a distintos niveles.
  • Bacula: herramienta muy completa que permite realizar backups de varios niveles (total, diferencial, incremental), de distintos clientes (linux, solaris, windows) y a diversos soportes (cinta y disco). Es software libre aunque tiene opción de soporte comercial.
  • Mondorescue: este software permite realizar backup de una instalación entera, y puede dejar las copias en numerosos soportes físicos.

4.3 · Bases de datos

Las bases de datos piden un trato especial. Guardar los ficheros que contienen las bases de datos no suele ser un buen sistema de backup, ya que una copia del fichero en un momento cualquiera puede generar una base de datos inconsistente. Por ello, cada servidor suele proporcionar un sistema de copias de seguridad, a menudo basadas en volcados de datos en distintos formatos.

  • MySQL: mysqldump realiza un volcado en los datos de la base de datos en SQL. Esto permite realizar backups y crear esclavos entre otros usos.
  • PostgreSQL: pg_dump hace, igual que mysqldump, un volcado de los datos en lenguage SQL.
  • SQL Server: el servidor de bases de datos de Microsoft ofrece la utilidad SQL Server Management Studio que permite programar las distintas tareas de backups, además de tareas previas y posteriores, especificando cuándo, de qué y a qué nivel se realiza la copia de seguridad de forma que sea consistente y fácilmente recuperable.

4.4 · Snapshots

Los snapshots son “fotografías” del sistema o de una parte que permiten recuperarlo en un estado que se sabe que es correcto. Los snapshots se pueden realizar a distintos niveles:

  • Sistema de ficheros: hay sistemas de ficheros que permiten realizar backups en forma de snapshots. ZFS dispone de esta utilidad.
  • Volúmen de disco: LVM ofrece esta posibilidad para recuperar volúmenes.
  • Máquinas virtuales: muchos gestores de máquinas virtuales permiten realizar snapshots de las mismas. KVM, Xen o VMWare entre otros disponen de esta característica.
  • Ficheros: con rsnapshot se pueden realizar backups en forma de snapshot aprovechando el rsync y mediante hardlinks de forma transparente. Back In Time también realiza snapshots de directorios, aunque únicamente para entornos de escritorio.

4.5 · Continuous Data Protection

Consiste en guardar automáticamente una copia de todos los cambios realizados en los datos, adquiriendo una copia remota de todas las versiones. Esto permite realizar recuperación de los datos de cualquier momento. Aunque hay sistemas optimizados para guardar únicamente las diferencias y ocupar poco espacio en disco, este sistema tiene penalizaciones en la red dada la continua transferencia de datos.

  • AIMstor: permite definir fácilmente políticas mediante una interfaz gráfica y soporta distintos tipus de backup, replicación y archiving.
  • RecoverPoint: soporta replicación remota de datos mediante protocolos síncronos y asíncronos.
  • InMage DR-Scout: tiene un repositorio de capacidad optimizada y soporta diversas plataformas (Windows, Linux, Solaris,…).

5 · A tener en cuenta

Con la infinidad de herramientas disponibles, la elección puede ser complicada. Para simplificar la búsqueda y reducir las opciones, es imprescindible definir las necesidades propias y lo que ofrecen las soluciones para encontrar la herramienta que mejor las cubra. Algunas cuestiones que pueden ayudar en la elección de una herramienta son las siguientes:

  • Instalación: ¿Está paquetizada o es necesario compilar? ¿Es fácil de instalar? ¿Tiene requerimientos especiales?
  • Configuración y mantenimiento: ¿Es fácil de mantener? ¿Es capaz de implementar la política? ¿Cuánto tiempo de aprendizaje requiere? ¿Tiene interfaz gráfica?
  • Restauración: ¿La restauración es fácil y rápida? ¿Puede un usuario restaurar un fichero suyo o debe ser siempre el administrador?
  • Compatibilidad: ¿Sirve para todos los sistemas de la plataforma? ¿El servidor debe correr en un sistema concreto?
  • Soporte físico: ¿Permite backup a cinta, DVD, sistemas de ficheros remotos, disco…?
  • Licencia: ¿Es software libre o comercial? ¿Dispone de soporte para empresas?

6 · Conclusiones

La variedad de opciones permiten definir ampliamente la política de backups de forma que se pueda utilizar una o varias herramientas para la misma plataforma, así como distintos niveles y retenciones para distintos ficheros. A menudo no hay una solución única y fija, y raramente la misma política sirve para dos plataformas diferentes.

Aunque es recomendable ser flexible para los pequeños cambios (la política o los recursos pueden sufrir modificaciones), realizar grandes cambios en el sistema de backups puede ser complejo, por lo que es importante realizar un buen estudio para escoger la mejor opción. La clave se encuentra en definir y cubrir las necesidades de cada plataforma ajustando el sistema a los recursos disponibles.

Sobre la autora

Foto de perfil de Alba Ferrer, Systems Engineer en CAPSiDE

Alba Ferrer es Ingeniera Informática por la Facultad de Informática de Barcelona (FIB/UPC) y Georgia Tech (USA), y Administradora de Sistemas (SysAdmin) en CAPSiDE. Activa dentro de la comunidad Perl de Barcelona y del grupo Sudoers de Barcelona. Miembro de las comunidades de Software Libre de Ubuntu (ubuntu.cat) y Caliu. Puedes seguir aquí sus tweets.

Categoría:

Consejos, Estándares, Opinión, ingeniería de sistemas

Etiquetado con:

¿Cómo conectar a un mirror server después de un failover en DB Mirroring de Microsoft SQL Server?

DB Mirroring copia todos los objetos de la base de datos del servidor principal al mirror server (servidor espejo o replicado).
De todos modos, esto no copia los inicios de sesión (o logins) del servidor principal al mirror o espejo, y esto comporta que después del failover no se pueda conectar a la base de datos del mirror server.

Para resolver este problema necesitamos conocer el SID del login en el servidor principal.
Cuando sepamos el SID del login, podemos crear un nuevo login en el mirror server utilizando este SID.

Para conocer el SID del login del server principal debemos ejecutar la siguiente sentencia en el servidor principal:

SELECT sid  FROM sys.server_principals where name = ‘<LoginName>’

Para crear el login en el mirror server utilizando el SID del servidor principal, podemos ejecutar la siguiente sentencia en el servidor espejo (mirror server):

CREATE LOGIN <LoginName> WITH PASSWORD = ‘<Paswword>’ sid = <sid for same login on principal server>

Recuerde que el <LoginName>, el <Password> y el <SID de login en el servidor principal> deben ser exactamente los mismos en ambos servidores: principal (main) y espejo (mirror).

Finalmente se debe cambiar la cadena de conexión de la aplicación incluyendo el parámetro de “failover partner”:

Data Source=myServerAddress;
Failover Partner=myMirrorServerAddress;
Initial Catalog=myDataBase;
User Id=sqluser;
Password=sqlpassword;

Sobre el autor

Toni Planas - Systems Engineer at CAPSiDE

Toni Planas es Ingeniero de Sistemas y forma parte del equipo de especialistas de CAPSiDE. A lo largo de su carrera profesional se ha convertido en especialista de tecnologías y soluciones de Microsoft, centrándose sobretodo en lo referente a Sistemas Operativos, Bases de Datos SQL Server y Soluciones de Correo/Mensajería.

Categoría:

Aplicaciones, Consejos

Etiquetado con:

¿Cómo hacer DB Mirroring utilizando certificados? (SQL Server 2008 R2)

A continuación facilitamos un método de puesta a punto de Mirroring de Base de Datos en SQL Server 2008 R2.
Las sentencias a ejecutar se encuentran organizadas por orden secuencial (o cronológico) de ejecución y clasificadas entre el servidor principal (o máster) y el de mirroring (o “reflejo de Base de Datos”).

Siguiendo los pasos estipulados en la tabla siguiente podrá configurar un sistema de DB Mirroring de SQL Server 2008 (R2).
Tenga en cuenta que es probable que su instalación de SQL Server o que su Base de Datos difiera del sistema estándar que comentamos. Recomendamos primero que comprenda el porqué de todos los pasos explicados a continuación y luego los aplique bajo su criterio según los requisitos de sus sistemas.

Principal
Mirror
Prepare instances
Create database
master key, if needed
USE master
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<strong password>’
GO
USE master
GO
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘<strong password>’
GO
If you want or
need  to delete the data base master key
USE master
GO
DROP MASTER KEY
GO
USE master
GO
DROP MASTER KEY
GO
Make certificates
USE master
GO
CREATE CERTIFICATE LAB_SRV1_cert
       WITH SUBJECT
= ‘LAB-SRV1
certificate’
GO
USE master
GO
CREATE CERTIFICATE LAB_SRV2_cert
       WITH SUBJECT
= ‘LAB-SRV2
certificate’
GO
If you want or need to
delete certificates
USE master
GO
DROP CERTIFICATE LAB_SRV1_cert
GO
USE master
GO
DROP CERTIFICATE LAB_SRV2_cert
GO
Create mirroring
endpoint
USE master
GO
CREATE ENDPOINT Endpoint_Mirroring

STATE =
STARTED

AS TCP (
      LISTENER_PORT=5022
      , LISTENER_IP = ALL

)

FOR DATABASE_MIRRORING(
      AUTHENTICATION
= CERTIFICATE
LAB_SRV1_cert
      , ENCRYPTION = REQUIRED ALGORITHM
AES
      , ROLE = ALL

)
GO
USE master
GO
CREATE ENDPOINT Endpoint_Mirroring

STATE =
STARTED

AS TCP (
      LISTENER_PORT=5022
      , LISTENER_IP = ALL

)

FOR DATABASE_MIRRORING(
      AUTHENTICATION
= CERTIFICATE
LAB_SRV2_cert
      , ENCRYPTION = REQUIRED ALGORITHM
AES
      , ROLE = ALL

)
GO
If you want or need to delete endpoint
USE master
GO
DROP ENDPOINT [Endpoint_Mirroring]
GO
USE master
GO
DROP ENDPOINT [Endpoint_Mirroring]
GO
Backup certificates
USE master
GO
BACKUP CERTIFICATE LAB_SRV1_cert

TO FILE
= ‘C:\BACKUPS\LAB_SRV1_cert.cer’
GO
USE master
GO
BACKUP CERTIFICATE LAB_SRV2_cert

TO FILE
= ‘C:\BACKUPS\LAB_SRV2_cert.cer’
GO
Copy certificates
between instances
Use any secure copy method
Use any secure copy method
Configure inbound connections
Create logins
USE master
GO
CREATE LOGIN LAB_SRV2_login

WITH PASSWORD
= ‘<strong
password>’
GO
USE master
GO
CREATE LOGIN LAB_SRV1_login

WITH PASSWORD
= ‘<strong password>’
GO
Create user for
login
USE master
GO
CREATE USER LAB_SRV2_user FOR
LOGIN LAB_SRV2_login
GO
USE master
GO
CREATE USER LAB_SRV1_user FOR
LOGIN LAB_SRV1_login
GO
Associate the
certificate with the user
USE master
GO
CREATE CERTIFICATE LAB_SRV2_cert
   AUTHORIZATION LAB_SRV2_user
   FROM FILE
= ‘C:\BACKUPS\LAB_SRV2_cert.cer’
GO
USE master
GO
CREATE CERTIFICATE LAB_SRV1_cert
   AUTHORIZATION LAB_SRV1_user
   FROM FILE
= ‘C:\BACKUPS\LAB_SRV1_cert.cer’
GO
Grant CONNECT
permission at login for the remote mirroring endpoint
USE master
GO
GRANT CONNECT

ON ENDPOINT::Endpoint_Mirroring TO
[LAB_SRV2_login]
GO
USE master
GO
GRANT CONNECT

ON ENDPOINT::Endpoint_Mirroring TO
[LAB_SRV1_login]
GO
Prepare database
Create database
CREATE DATABASE [DBMTest] ON  PRIMARY
 (NAME =
N’DBMTest’,
   FILENAME = N’C:\MSSQL\DATA\DBMTest.mdf’)
LOG ON
 (NAME =
N’DBMTest_log’            ,
   FILENAME = N’C:\MSSQL\DATA\DBMTest_log.ldf’)
GO
USE [DBMTest]
GO
CREATE TABLE [dbo].[TTest](

[ID] [int] IDENTITY(1,1) NOT NULL,

[DayAndTime] [datetime] NOT NULL
)
GO
Backup database
BACKUP DATABASE [DBMTest]

TO
DISK =
N’C:\BACKUPS\DBMTest.bak’
   WITH NOFORMAT,
   INIT, 

NAME = N’DBMTest-Full
Database Backup’,
   SKIP,
   NOREWIND,
   NOUNLOAD, 
   STATS =
10
GO
Backup transaction
log
BACKUP LOG [DBMTest]
   TO DISK = N’C:\BACKUPS\DBMTest_log.bak’
   WITH NOFORMAT,
   INIT, 

NAME = N’DBMTest-Transaction
Log  Backup’,
   SKIP,
   NOREWIND,
   NOUNLOAD, 

STATS =
10
GO
Restore database
RESTORE DATABASE [DBMTest]
   FROM
DISK =
N’C:\BACKUPS\DBMTest.bak’
   WITH
FILE =
1, 
   MOVE N’DBMTest_log’
TO N’C:\MSSQL\DATA\DBMTest.ldf’,
   NORECOVERY,

NOUNLOAD, 

STATS =
10
GO
Restore transaction
log
RESTORE LOG [DBMTest]

FROM
DISK =
N’C:\BACKUPS\DBMTest_log.bak’
   WITH
FILE =
1, 
   NORECOVERY, 
   NOUNLOAD, 
   STATS =
10
GO
Configure the mirroring
partners and start mirroring
First, on the mirror
instance
ALTER DATABASE DBMTest

SET PARTNER
= ‘TCP://LAB-SRV1:5022′
GO
And then, on
the principal instance
ALTER DATABASE DBMTest

SET PARTNER
= ‘TCP://LAB-SRV2:5022′
GO
Configure performance
and safety mode
High performance (asynchronous
mode)
ALTER DATABASE DBMTest SET
PARTNER SAFETY
OFF
GO
High safety
(synchronous mode)
ALTER DATABASE DBMTest SET
PARTNER SAFETY
FULL
GO
Managing database
mirroring
Pause mirroring
ALTER DATABASE DBMTest SET PARTNER SUSPEND
Resume mirroring
ALTER DATABASE DBMTest SET PARTNER RESUME
Manual failover (asynchronous
mode)
ALTERDATABASE DBMTest SET SAFETY FULL
GO
ALTERDATABASE DBMTest SET PARTNER FAILOVER
GO
ALTERDATABASE DBMTest SET SAFETY FULL
GO
Manual failover
(synchronous mode)
ALTERDATABASE DBMTest SET PARTNER FAILOVER
GO
Remove database mirroring
ALTER DATABASE DBMTest SET PARTNER OFF

Sobre el autor

Toni Planas - Systems Engineer at CAPSiDE

Toni Planas es Ingeniero de Sistemas y forma parte del equipo de especialistas de CAPSiDE. A lo largo de su carrera profesional se ha convertido en especialista de tecnologías y soluciones de Microsoft, centrándose sobretodo en lo referente a Sistemas Operativos, Bases de Datos SQL Server y Soluciones de Correo/Mensajería.

Categoría:

Consejos

Etiquetado con:

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.