Social Icons

twitter facebook google plus linkedin

Featured Posts

miércoles, 4 de abril de 2018

Mover base de datos de una region a otra en Azure

Hola mundo:
En esta entrega, revisaremos un procedimiento altamente solicitado por administradores de infraestructura en Azure. Este consiste en migrar una base de datos de una región a otra con muy bajo downtime y, prácticamente, sin pérdida de datos, utilizando la geo replicación y las características de alta disponibilidad.

Para este ejemplo, tendré una base de datos de prueba (AdventureWorks)  en la región East US. Para efectos de la prueba, es una base de datos de bajo costo.

Dentro del panel del recurso, iremos al menú de la izquierda y ubicaremos la opción Geo-Replication


Abrirá una ventana asi. Se muestra un mapa con las regiones disponibles para hacer la replicación

Para hacer la replicación, escogeré la región West US 2 del listado. Una vez seleccionada la región, abrirá un asistente donde se pide configurar algunos parámetros. Entre los parámetros a configurar es la creación de un servidor SQL Server donde residirá la base de datos réplica. 

Una vez seteados los parámetros, la replicación comenzará a ejecutarse:

 
Aparece la base de datos replicada en el apartado de Secondaries y en el mapa se ve una gráfica de la replicación.
Al entrar en la réplica de la base de datos, veremos la opción de hacer un failover forzado.


Al hacer el failover aparece una advertencia diciendo que todas las sesiones van a ser desconectadas y que podría perder datos. Entendiendo los riesgos, procedemos.
Al volver a la vista principal de geo replicación, se ve que el estado de la base de datos secundaria está en proceso de failover.

Luego de esperar el cambio, se puede observar que la base de datos secundaria ya es primaria:

Ahora queda cumplir el cometido: Eliminar la base de datos para que solo quede en una sola region. Para esto hay que ir a la vista de las bases de datos y eliminar la que corresponde. Tomar en cuenta que aparece cual es el rol de la base de datos (primaria o secundaria). 

Confirmación de eliminación

Con este procedimiento, la geo replicación queda desactivada y la base de datos operando en la nueva región.  Es importante cambiar la conexión en las aplicaciones que hagan uso de esta base de datos. Recordar que es un nuevo servidor SQL Server, con un nombre distinto.

Espero que les sea de utilidad.


miércoles, 24 de enero de 2018

Autenticación remota a SQL y error de certificado

Hola Mundo:
¡Uf! bastante tiempo sin dedicarle unas líneas al blog que me ha acompañado por un poco más de 10 años. Que ha sido testigo de mi aprendizaje y de mis experiencias en el mundo de bits y bytes.

Hoy he vuelto con la solución a un problema recurrente al momento de conectarse a un origen de datos como SQL Server.



La cadena de certificación fue emitida por una entidad en la que no se confía
----------------------------
La conexión con el servidor se ha establecido correctamente, pero se ha producido un error durante el proceso de inicio de sesión. (provider: SSL Provider, error: 0 - La cadena de certificación fue emitida por una entidad en la que no se confía.)

Para las conexiones remotas a SQL Server, el servidor requiere de un certificado que debe ser importado en las máquinas donde se realizará la conexión.

Desde el servidor,  abrir el contenedor de certificados y navegar hacia la ruta de la imagen:


En el cliente, el certificado se debe importar en:

y listo.

Espero que les sirva

miércoles, 20 de septiembre de 2017

Recomendaciones para la administración de logs de IIS

Hola Mundo

Internet Information Services es el servidor de aplicaciones incluido como rol dentro de Windows Server, que otros roles y plataformas utilizan para poder dar servicios a la red en la que están inmersos. 

Cada transacción genera una entrada en el registro de log de IIS. Estos registros contienen con precisión el quién, qué, dónde, cuándo y cómo de la transacción. En sistemas altamente concurrentes, el tamaño de los log puede volverse inmanejable. 

 Es altamente aconsejable tener en vista el crecimiento del directorio , con alguna herramienta de monitoreo, o bien, revisando periódicamente con alguna herramienta para estos fines, como WinDirStat (herramienta de terceros gratuita). 
%SystemDrive%\inetpub\LogFiles

 Para poder tener un mayor control para el posterior análisis, se recomienda partir configurando en IIS:

  • Centralized Binary Logging. Esta configuración permite preservar los recursos de memoria, disminuyendo la cantidad de archivos de log. Manejando un único archivo de datos no formateados. 
  • Crear archivos separados para los distintos sitios web y aplicaciones. Limitar la cantidad de campos que se registran. Registrar solo lo estrictamente necesario. 


 A nivel de sistema de archivos también se pueden hacer cambios en el tratamiento del directorio de logs y es comprimiendo el directorio. Esto se consigue con privilegios de administración sobre el sistema y entrando a las propiedades avanzadas del directorio. Habilitando la compresión, el volumen del directorio será de solo un 2% del tamaño original. Almacenar los log en un directorio remoto es una buena forma, pero hay que considerar el alto trabajo de la red y recursos externos para el correcto funcionamiento.  Recordar que son sistemas intensivos en el uso de recursos. 

 Cuando la administración no es adecuada, el directorio crece y es necesario eliminarlos directamente desde el directorio. La operación no requiere detener el servicio. Se recomienda partir eliminando los más antiguos. 

 La administración y el monitoreo correcto de los log de IIS aseguran la continuidad operativa del sistema en general y ayuda al cuidado de los recursos de disco del servidor. Si se quiere ir más allá, siempre es una opción hacer inteligencia sobre los archivos de log con alguna solución de Big Data.

jueves, 24 de agosto de 2017

Habilitar usuario root y permitir login por ssh

Hola Mundo:
Ubuntu impuso la moda de deshabilitar el usuario root y que todas las operaciones que requerían privilegios se hicieran a través de sudo. Esto fue una ventaja desde el punto de vista de seguridad, ya que la superficie expuesta era mucho menor. 

El procedimiento es sencillo, pero hay que tener consideración con la seguridad.

sudo passwd root

Con esto se le asigna una contraseña al usuario root. Para permitir el acceso por ssh hay que ir a /etc/ssh/sshd_config y buscar la opcion PermitLogin y dejarla en yes.


Luego se reinicia el servicio

sudo /etc/init.d/sshd restart

Con esta configuración aplicada ya estarían en condiciones de usar el usuario root.

Espero que hayan disfrutado este micro post.