Muita gente já conhece ou já ouviu falar da possibilidade de instalar o SQL Server em modo silencioso/unattended, mas o que alguns não sabem é que é possível inclusive fazer a instalação de uma Failover Cluster Instance (FCI) através desse modo.
Alguém pode perguntar o motivo de realizar a instalação do cluster via modo silencioso, mas imagine o tempo que se “perde” ao fazer uma instalação de várias instâncias “normais” via GUI e agora considere o fato de que em uma FCI são necessários mais passos durante a instalação. Resumindo, a economia de tempo é ainda maior (sem contar a segurança de ter o ambiente padronizado, sem riscos de erros de digitação, ou pelo menos com risco reduzido).
Bem, o processo de instalação em si é praticamente o mesmo, a diferença é que temos alguns parâmetros diferentes ou adicionais a informar.
Eu prefiro trabalhar do seguinte modo, deixo todos os parâmetros que serão iguais para todoas as instâncias no configuration file (.ini) e passo os demais parâmetros na linha de comando com os valores que mudam para cada instância. Desse modo tenho um único configuration file.
Na verdade no meu ambiente fiz 2 tipos de configuration files, um para ambientes OLTP “convencionais” e outro para ambientes de BI (onde instalo também SSAS, SSIS, SSRS e, consequentemente, possui vários parâmetros adicionais).
Na instalação de uma FCI, eu prefiro utilizar o modo advanced, realizando o “prepare” do ambiente e depois o “complete” do mesmo.
Dessa forma uma possível linha de comando (aberta como ADMINISTRADOR, cuidado com o UAC!) para o “prepare”, que deve ser executado em todos os nós, poderia ser essa (estou utilizando o exemplo de um ambiente de BI):
setup.exe /ConfigurationFile=C:\SQL\ConfigurationFile_Prepare_BI.ini /AGTSVCPASSWORD=”senha” /SQLSVCPASSWORD=”senha” /ASSVCPASSWORD=”senha” /ISSVCPASSWORD=”senha” /RSSVCPASSWORD=”senha” /INSTANCENAME=”BI” /INSTANCEID=”BI”
Os parâmetros são todos muito bem documentados e informações mais detalhadas sobre os mesmos e sobre o processo de instalação em si podem ser encontrados na documentação oficial.
No configuration file, foram fornecidos os seguintes parâmetros:
- ACTION=”PrepareFailoverCluster”
- ENU=”True”
- QUIET=”True”
- QUIETSIMPLE=”False”
- UpdateEnabled=”True”
- FEATURES=SQLENGINE,REPLICATION,FULLTEXT,DQ,AS,RS,RS_SHP,RS_SHPWFE,DQC,BIDS,IS,SSMS,ADV_SSMS
- UpdateSource=”C:\SQL”
- HELP=”False”
- INDICATEPROGRESS=”False”
- X86=”False”
- INSTALLSHAREDDIR=”C:\Program Files\Microsoft SQL Server”
- INSTALLSHAREDWOWDIR=”C:\Program Files (x86)\Microsoft SQL Server”
- SQMREPORTING=”False”
- RSINSTALLMODE=”FilesOnlyMode”
- RSSHPINSTALLMODE=”SharePointFilesOnlyMode”
- ERRORREPORTING=”False”
- INSTANCEDIR=”C:\Program Files\Microsoft SQL Server”
- AGTSVCACCOUNT=”domínio\conta”
- ISSVCSTARTUPTYPE=”Automatic”
- ISSVCACCOUNT=”domínio\conta”
- ASSVCACCOUNT=”domínio\conta”
- ASSVCSTARTUPTYPE=”Manual”
- ASPROVIDERMSOLAP=”1″
- FILESTREAMLEVEL=”0″
- SQLSVCACCOUNT=”domínio\conta”
- RSSVCACCOUNT=”domínio\conta”
- RSSVCSTARTUPTYPE=”Automatic”
- FTSVCACCOUNT=”NT Service\MSSQLFDLauncher$BI”
O único parâmetro dessa linha de comando que eu gostaria de comentar aqui é o /UpdateSource, que informa onde estão os arquivos de atualização (Hotfixes, Cumulative Updates, Service Packs, inclusive vários ao mesmo tempo) que você possa querer aplicar já durante a atualização, o que certamente é uma boa prática e que vai te economizar um bom tempo.
Já para o “Complete”, que só precisa ser executado em um dos nós, uma possível linha de comando seria:
setup.exe /ConfigurationFile=C:\SQL\ConfigurationFile_Complete_BI.ini /INSTANCENAME=”BI” /FAILOVERCLUSTERDISKS=”Nome do Disco” /FAILOVERCLUSTERGROUP=”SQL Server (BI)” /FAILOVERCLUSTERIPADDRESSES=”IPv4;00.000.000.000;DMZ_ADM;255.255.255.0″ /FAILOVERCLUSTERNETWORKNAME=”nome de rede” /INSTALLSQLDATADIR=X:\ /SQLBACKUPDIR=X:\ /SQLUSERDBDIR=X:\ /SQLUSERDBLOGDIR=”X:\mount_point\LOG” /SQLTEMPDBDIR=X:\ /SQLTEMPDBLOGDIR=”X:\mount_point\LOG” /SAPWD=”senha” /ASDATADIR=”X:\OLAP\Data” /ASLOGDIR=”X:\OLAP\Log” /ASBACKUPDIR=”X:\OLAP\Backup” /ASTEMPDIR=”X:\OLAP\Temp” /ASCONFIGDIR=”X:\OLAP\Config”
Obviamente as informações fornecidas aqui foram “mascaradas” para não passar nenhuma informação confidencial, mas vejam que no exemplo eu uso mount points, o que em um ambiente com várias instâncias ajuda bastante e que, neste artigo pelo menos, não irei detalhar mais (há bastante documentação na internet).
No configuration file de complete haviam os parâmetros abaixo:
- ACTION=”CompleteFailoverCluster”
- ENU=”True”
- ; UIMODE=”Normal” (comentado, será necessário mais adiante)
- QUIET=”False”
- QUIETSIMPLE=”True”
- HELP=”False”
- INDICATEPROGRESS=”False”
- X86=”False”
- CONFIRMIPDEPENDENCYCHANGE=”False”
- ASCOLLATION=”collation”
- ASSYSADMINACCOUNTS=”domínio\conta”
- ASSERVERMODE=”MULTIDIMENSIONAL”
- SQLCOLLATION=”collation”
- SQLSYSADMINACCOUNTS=”domínio\conta”
- SECURITYMODE=”modo”
Na verdade o parâmetro QUITESIMPLE normalmente ficaria como FALSE e o QUITE como TRUE, para deixar o processo totalmente em background, mas foi uma opção minha inverter os valores para ver algumas informações durante os testes. Vou explicar mais adiante o motivo.
O processo em si da instalação é bem simples e não é comum enfrentar muitos problemas, mas você precisa prestar atenção a alguns detalhes que podem dar alguma dor de cabeça.
O primeiro deles é o formato dos paths que, se informados de maneira “não padronizada”, podem gerar erros na instalação. Uma boa documentação para tal se encontra nesse link.
Já outro problema interessante que eu enfrentei, e o mais curioso, foi o fato de que o nome dos /FAILOVERCLUSTERDISKS são CASE SENSITIVE. Eu pelo menos nunca havia visto ninguém comentar ou alguma documentação a respeito, mas passei por isso recentemente e, após receber algumas mensagens de “folder path is invalid” ou “The volume that contains SQL Server data directory X:\MSSQL11.Instância\MSSQL\DATA does not belong to the cluster group.”, mesmo seguindo as recomendações do link que citei agora a pouco, verifiquei esse fato.
No meu caso o problema foi um pouco mais complicado, pois não havia mensagem citando o disco, mas após remover e adicionar os discos da instância novamente aos recursos do cluster do windows passei a receber a mensagem mais detalhada sobre o disco.
No caso de algum problema e você necessite realizar um troubleshooting há alguns parâmetros que podem te ajudar. Os primeiros, que acabo de mostrar, são QUIET e QUIETSIMPLE. Inverter seus valores não dará muitas informações, apenas exibirá algumas telas onde não será necessária internvenção, mas já te permite ter uma noção de onde ocorre o problema.
Outra opção interessante é deixar QUIET e QUITESIMPLE como FALSE e mudar o parâmetro UIMODE para “Normal” (no meu exemplo acima, apenas tirar o ; da frente para que não fique como comentário). Esse parâmetro, aliado ao fato de que fornecemos um configuration file e uma série de parâmetros, fará com que a GUI seja exibida e você precise navegar pelas telas de instalação, mas já com os valores, já fornecidos, estejam todos preenchidos. Isso permite que você verifique se alguma tela apresenta erro nos parâmetros informados e possa então corrigí-lo no configuration file ou nos parâmetros da linha de comando. Isso por exemplo me deu uma dica sobre o problema com o nome do disco ser CASE SENSITIVE que citei anteriormente, mas na hora eu não entendi. Com o nome do disco em minúsculas nos parâmetros e em maiúsculas no cluster, ao chegar na tela do disco ele nunca vinha selecionado, mas eu pensava que era apenas alguma falha da GUI, mas não, estava demonstrando exatamente qual era o problema.
Uma última dica é verificar os registros do arquivo detail.txt na pasta de log da instalação (C:\Program Files\Microsoft SQL Server\110\Setup Bootstrap\Log\ e acessar a pasta com data e hora da instalação). Nele são registradas todas as mensagens da instalação. Caso queira, você pode utilizar o parâmetro /INDICATEPROGRESS como TRUE para que ele jogue no prompt as mensagens da instalação e acompanhar as saídas na tela durante a instalação.
Links complementares:
Vladimir M. B. Magalhães - Learn and Share 