Para realizar la conexión al servidor SQL Server, tenemos la opción de especificar sus verdaderos datos de conexión, o por el contrario, crear un Alias SQL y especificar como datos de conexión el Alias SQL que hemos creado. Un Alias SQL no es más que la definición de un nombre, al cual, asociamos unos datos de conexión (Protocolo de Red utilizado, y datos necesario para conectar a SQL Server a través de dicho Protocolo. Ej: Protocolo TCP/IP, nombre de servidor, nombre de instancia y puerto). La ventaja de utilizar un Alias SQL, es la abstracción, pues con esta técnica conseguimos que SharePoint sólo se preocupe de conectarse a la base de datos conforme la definición del Alias SQL especificado, por lo cual, si en un futuro se cambia el servidor de base de datos (ej: una migración de SQL Server), será suficiente con actualizar el Alias SQL que utiliza SharePoint para conectarse, sin mayor preocupación.
Con todo esto, creo que queda clara la utilidad de un Alias SQL, es decir, prácticamente ninguna. Recordemos que también existe una cosa llamada DNS, de tal modo que ante una migración podemos modificar o crear los registros DNS correspondientes para conseguir engañar a los equipos clientes, y redireccionarlos a la dirección IP que deseemos, ¿verdad? Visto así, pinta más útil la utilización de DNS que la utilización de Alias SQL, aunque lo bueno del Alias SQL es que su modificación sólo afecta al equipo cliente en que se crea o modifica dicho Alias SQL (un cambio en DNS afecta a todos los clientes DNS de la organización).
Sin embargo, la verdadera utilidad de los Alias SQL está en utilizar Database Mirroring como método de Alta Disponibilidad. Pero claro, aquí surge la duda ¿porqué utilizar Database Mirroring como método de Alta Disponibilidad, pudiendo utilizar un Cluster de SQL Server? Pues el principal motivo, es porque no está soportado el funcionamiento de MOSS sobre un Cluster Geográfico, por lo tanto, si tenemos dos CPD y queremos dotar de alta disponibilidad a nuestra solución MOSS en caso de pérdida de un CPD, deberemos utilizar Database Mirroring. En este escenario, en el caso de la pérdida del CPD en el cuál actúa la base de datos principal (bueno... las bases de datos principales, que son varias ;-), deberemos alterar los Alias SQL en los servidores MOSS para que se conecten al servidor SQL Server que se mantiene vivo en el CPD de Respaldo, y así mantener la continuidad del servicio (joder, que bonito… si al final lo de ITIL va a ser verdad y todo ;-).
Sin extendernos más, sólo comentar que para configurar un Alias SQL (que por cierto, lo deberemos de realizar en cada uno de los servidores MOSS que necesiten conectarse a SQL Server), deberemos ejecutar la utilidad cliconfg.exe (SQL Server Client Network Utility), y en la pestaña Alias añadir (Add) uno nuevo.
Especificaremos el nombre del Alias SQL (ej: MOSSSQL), el protocolo deseado (ojo, en ocasiones me he encontrado problemas con TCP/IP y he tenido que utilizad Names Pipes - Canalizaciones con nombre - para poder conectarme), y el resto de datos de conexión.
Aceptaremos, y el Alias SQL ya estará creado.
Resulta realmente sencillo, eso sí, en caso de utilizar Database Mirroring y producirse un balanceo, deberemos modificar los Alias SQL en todos los equipos que accedan al Mirror (teniendo en cuenta que deberán estar todas las bases de datos en la misma máquina, etc.). Bueno, realmente hay varias alternativas de Diseño de Database Mirroring con MOSS (realmente, no es requisito indispensable que estén todas las bases de datos en la misma máquina), pero queda fuera del alcance de este artículo entrar en mucho detalle... sólo quiero introducir un poco el tema del Alias SQL, al menos, de momento.
