HomeLab – Porque mudei para o Hyper-V

Há muito tempo atrás, numa galáxia distante, comecei uma pós-graduação em perícia digital. O curso era uma avalanche de informação técnica sobre redes e segurança e estava tão relacionado ao meu trabalho do dia a dia quanto um curso de barista: Ambos são muito bacanas e podiam me trazer benefícios no ambiente de trabalho – quem não gosta de café na TI –, mas eu os faria apenas por interesse pessoal. No entanto, pouco antes de me matricular, descobri que o curso seria 90% em Linux e eu nunca havia mexido com esse pinguim.

Então, surgiu a necessidade de criar máquinas virtuais e a turma de perícia optou pelo Virtual Box. Confesso que me apeguei rapidamente ao VBox e, logo, estava usando ele em casa, no notebook e no trabalho. Pela linha de comando, ele é uma ferramenta flexível que atende muito bem às necessidades de um HomeLab. Através da interface gráfica, nem tanto.

Apesar disso, quando comecei a utilizar VMs para instalação de Failover Clustered Instances, me deparei com um bug da ferramenta. Sempre que as ferramentas de integração com o host (VirtualBox Guest Tools) estavam instaladas na VM, a instalação da FCI falhava. E é claro que muita gente deu de cara com esse bug [1]. Logo, como o meu foco era exatamente FCIs, resolvi tentar outra plataforma de virtualização.

O fato é que a maior ferramenta do mercado é a VMware. Porque não ir diretamente para ela? Depois do lançamento do PowerCLI [2], a integração entre host e guest era quase perfeita. Sem falar que ela sempre esteve no topo do mercado… Mas qual outra opção está próxima à VMware? O Gartner responde [3].

gartner_virtualization_2016

Hyper-V… Really?!

Fiquei tão surpreso de ver o Hyper-V em segundo lugar que fui pesquisar mais e descobri que ele tem crescido bastante nos últimos anos. E agora, Hyper-V ou VMware?

Em questão de compatibilidade, não tem o que comentar sobre o virtualizador da Microsoft. Com o crescimento dessa ferramenta nos últimos anos, fica difícil dizer que não vale investir o seu tempo nela. Apenas se ela tivesse algo como o PowerCLI…

HAIL POWERSHELL DIRECT!

Foi então que descobri a nova funcionalidade do powershell nos Windows 10 e Windows Server 2016: Powershell Direct [4]. Com ele, você é capaz de executar comandos diretamente nas VMs sem precisar de configuração de remote desktop, firewall ou rede… Não sei como demonstrar o quão simples e conveniente é este recurso senão através de um exemplo!

#Nome da VM
$VmName = "WS2016-DC"

#Credencial para logar na VM
$VmCredential = Get-Credential -Credential "$VmName\administrator"

#Executar comandos dentro da VM
Invoke-Command -VMName $VmName -Credential $VmCredential -ScriptBlock {
    #Capturar o adaptador de rede
    $NetAdapter = Get-NetAdapter

    #Renomear para facilitar identificação
    $NetAdapter | Rename-NetAdapter -NewName "LAN_NIC"

    #Atribuir novo IP ao adaptador de rede
    New-NetIPAddress -InterfaceIndex $NetAdapter.ifIndex `
        -AddressFamily "IPv4" `
        -IPAddress "11.1.1.1" `
        -PrefixLength "24" `
        -DefaultGateway "11.1.1.1"

    #Configurar o endereço do DNS
    Set-DnsClientServerAddress -InterfaceIndex $NetAdapter.ifIndex -ServerAddresses "127.0.0.1"

    #Renomear a máquina
    Rename-Computer -NewName "WS2016-DC" -Restart
}

Nesse script, estou entrando com as credenciais de administrador da minha VM – um prompt será exibido para que digite a senha – e usando o cmdlet “Invoke-Command” para rodar comandos diretamente na “WS2016-DC”. Tudo que está dentro de “ScriptBlock”, da linha 8 até a linha 27, será executado como se estivesse dentro do console do powershell da VM. Se você tem acompanhado a série de publicações do HomeLab, perceberá que o script executado é parte da configuração da minha domain controller [5]. Em outras palavras, preciso apenas criar a VM e posso realizar toda a configuração através do próprio host!

Depois de descobrir o Powershell Direct, as possibilidades são diversas! Hoje, tenho labs com diversas configurações de AlwaysOn (FCIs e AGs) completamente automatizadas, basta executar um script! Difícil é não se acostumar com as facilidades providas por este recurso… E é por isso que utilizo o Hyper-V hoje. E você, qual virtualizador usa?

LINKS

[1] https://www.sqlskills.com/blogs/jonathan/building-a-completely-free-playground-for-sql-server-4-creating-the-cluster/

[2] https://blogs.vmware.com/PowerCLI/

[3] https://www.gartner.com/doc/reprints?ct=160707&id=1-3B9FAM0&st=sb

[4] https://blogs.technet.microsoft.com/virtualization/2015/05/14/powershell-direct-running-powershell-inside-a-virtual-machine-from-the-hyper-v-host/

[5] https://comunidadesqlserver.wordpress.com/2017/01/02/homelab-crie-e-configure-um-dominio/

Anúncios

HomeLab – Crie um Storage Server com iSCSI Target usando Powershell

Quando começamos a testar soluções de alta disponibilidade em nosso home lab, logo damos de cara com uma realidade cruel: nem todos têm acesso à uma storage. Eu nunca tive… (Insira cara triste aqui).

Uma solução prática para esse problema é utilizar um iSCSI Target para entregar discos como um Storage Server faria. Desde o Windows Server 2012, esta tecnologia vem disponível como uma built-in feature. No entanto, antes de começarmos a codificar algo, vejamos o basicão sobre este recurso.

Nota: Estes scripts foram desenvolvidos e testados num ambiente Windows 10\Windows Server 2016 com Powershell 5.0. O funcionamento de cada cmdlet pode variar de acordo com a versão.

HTH DOES THIS WORK?

Um iSCSI Target Server é um servidor que irá compartilhar discos virtuais através do iSCSI Target para outros servidores, chamados de iSCSI Initiators. Para um initiator se conectar a um target server, ele realiza uma iSCSI Connection sobre TCP/IP até o Target. O target é um objeto que possui registros de quais initiators podem se conectar a ele e também de todos iSCSI Virtual Disks associados. Estes discos virtuais são criados no target server e, depois, serão montados em um ou mais initiators. Acho que com um desenho fica um pouco mais fácil de entender.

iscsi-target

Neste caso, temos o initiator com dois discos virtuais montados como suas unidades F e G. Como boa prática – e para facilitar um bocado o gerenciamento –, é indicado nomear os discos virtuais de forma a identificar prontamente a quais estes estão associados. Os discos virtuais foram criados em cima da unidade Z do Target Server, mas poderiam ter sido criados em unidades diferentes.

Como a minha ideia é apenas te familiarizar com alguns termos e com o funcionamento desse recurso, vamos seguir em frente. No entanto, caso tenha interesse em começar a estudar sobre este assunto, sugiro começar por aqui [1].

READY TO WORK!

Agora que já entendemos um pouquinho sobre iSCSI Target, vamos à prática. Vou utilizar uma VM que sempre estará ligada para servir como iSCSI Target Server e, pra mim, esta VM é minha Domain Controller [2]. Ela servirá os discos para uma máquina chamada SQLNODE01 – é, bem original, eu sei… A configuração deste ambiente é a seguinte:

tabela

Na VM “WS2016-DC” temos a unidade Z que será usada para criar um disco virtual. Este disco será entregue ao “SQLNODE01” e montado localmente.

Incialmente, iremos até nosso iSCSI Target Server e instalaremos a feature de mesmo nome. Depois, criaremos o target que irá possibilitar a conexão dos discos com os initiators. Note que já iremos associar o endereço IP do SQLNODE01 ao target, mas este procedimento poderia ser realizado posteriormente. Em seguida, criaremos o disco virtual e vamos mapeá-lo ao target que criamos.

#Instalar a feature iSCSI Target Server
Install-WindowsFeature FS-iSCSITarget-Server

#Criar o Target e definir o Initiator que poderá conectar
$TargetName = "Sqlnode01-Target"
New-IscsiServerTarget -TargetName $TargetName `
-InitiatorIds "IPAddress:11.1.1.2"

#Adicionar descrição do Target
Set-IscsiServerTarget -TargetName $TargetName `
-Description "Target para servidor SQLNODE01"

#Criar disco virtual
$VhdPath = "Z:\iSCSIVirualDisks\SQLNODE01-F-SQLDATA.vhdx"
New-IscsiVirtualDisk -Path $VhdPath `
-Description "Disco usado para instância de SQLNODE01" `
-SizeBytes 100GB

#Mapear disco ao Target
Add-IscsiVirtualDiskTargetMapping -TargetName $TargetName -Path $VhdPath

Adicionei algumas descrições do target e do disco virtual para facilitar a administração desses objetos futuramente. Esses detalhes são opcionais, mas recomendados.

Agora, no SQLNODE01, precisamos configurar o serviço “Microsoft iSCSI Initiator” (MSiSCSI) para iniciar automaticamente com a VM e iniciá-lo para que possamos nos conectar ao target. Para isso, criaremos um portal apontando para o nosso target. Ao criar o portal, o target ficará visível e com isso conseguiremos nos conectar. É através desta conexão que teremos acesso ao disco virtual. Finalmente, basta inicializar o disco, criar uma partição e formatar.

#Configurar serviço para iniciar automaticamente
Set-Service -Name MSiSCSI -StartupType Automatic

#Iniciar o serviço
Start-Service MSiSCSI

#Criar portal para o Target
New-IscsiTargetPortal –TargetPortalAddress 11.1.1.1

#Recuperar e conectar-se ao Target
Get-IscsiTarget | Connect-IscsiTarget -IsPersistent $true

#Recuperar discos disponíveis através da conexão
$iSCSIVirtualDisk = Get-iSCSIConnection | Get-Disk

#Inicializar o disco e criar a partição F
$iSCSIVirtualDisk | Initialize-Disk -Passthru | `
New-Partition -DriveLetter F -UseMaximumSize

#Formatar o volume
Format-Volume -DriveLetter F -FileSystem NTFS `
-NewFileSystemLabel "SQLDATA" -AllocationUnitSize 64KB

Um detalhe que vale ser ressaltado: A flag “IsPersistent” foi marcada como “True” para que a conexão com o Target seja reestabelecida sempre que a VM for iniciada.

Pronto! Agora temos um Storage Server entregando um disco para a VM SQLNODE01 e que  também poderá entregar discos para todas as VMs em nosso Home Lab. Aproveito para deixar uma pergunta para você: Qual seria o procedimento se quiséssemos compartilhar um mesmo disco para mais de uma VM?

LINKS

[1] https://blogs.technet.microsoft.com/filecab/2012/05/21/introduction-of-iscsi-target-in-windows-server-2012/

[2] https://comunidadesqlserver.wordpress.com/2017/01/02/homelab-crie-e-configure-um-dominio

Retrospectiva 2016

Esta publicação é uma forma de agradecermos você, leitor. Mais um ano terminado e nossa Comunidade SQL Server continua crescendo! Neste ano que passou, tivemos mais visualizações e visitantes em relação aos anos anteriores. Números, estes, que trazem satisfação de publicar e compartilhar conteúdo e experiências com vocês.

img01

De todo o conteúdo que vocês tiveram acesso, as cinco publicações mais visualizadas em 2016 foram:

  1. Atachar/Recuperar arquivos MDF sem o LDF
  2. Tabelas Temporárias X Variáveis de Tabela
  3. Como verificar o HASH de um arquivo?
  4. Tabelas Temporais – Parte 1: Criação de tabelas
  5. Trabalhando com dados hierárquicos – Parte III

O ano de 2016 também foi recheado de eventos da comunidade técnica e estivemos presentes em vários deles como:

Sem falar em tantos outros eventos que gostaríamos de ter participado! Neste ano, a ideia é aumentar este número, incluindo eventos que ainda não participamos!

Tive a oportunidade de palestrar três vezes neste ano que passou e pretendo palestrar mais vezes. Palestrei junto com a Nane também que foi uma experiência muito divertida e gratificante.

Pude começar a aprender Powershell. Algo que sempre achei interessante, mas que nunca esteve no topo da lista. Hoje, vejo o quanto esta ferramenta é útil. Portanto, pretendo escrever mais sobre ela.

Consegui sair um pouco da minha linha “dev” e estudar um pouco mais sobre tecnologias de alta disponibilidade no SQL Server. É empolgante e, ao mesmo tempo, um pouco assustador ver o quanto você tem a aprender sobre outras áreas dessa plataforma de dados – vou nem mencionar a área de BI…

Pude gravar um mini curso online sobre Always Encrypted para um site de tecnologia que deverá ficar disponível em breve – se tudo der certo. Uma experiência bem enriquecedora no aspecto didático. Quem sabe no futuro eu gravo mais alguns.

E assim foi 2016… Espero que continue conosco no ano de 2017 e, mais uma vez, obrigado pela companhia!

[]’s

HomeLab – Crie e Configure um Domínio

Uma das necessidades mais comuns, quando se está criando ou testando algo no seu Home Lab, é a existência de um domínio. Para isso, precisamos de uma máquina que servirá de Domain Controller (DC).

Vou supor que você possui uma VM zerada. Assim, você pode pular quaisquer etapas que quiser. Vou supor também que utilizará essa mesma máquina como DNS Server, já que o nosso foco (na maioria das vezes) é o SQL. Um último detalhe: como executaremos tudo via powershell, você poderá utilizar este procedimento tanto para a versão “Desktop Experience” como para a versão “Core” do Windows Server.

Nota: Estes scripts foram desenvolvidos e testados num ambiente Windows 10\Windows Server 2016 com Powershell 5.0. O funcionamento de cada cmdlet pode variar de acordo com a versão.

MÃOS À OBRA

Uma das primeiras coisas que costumo fazer ao configurar um novo Domain Controller é determinar qual será seu endereço IP. O procedimento abaixo pode ser ajustado e repetido caso você esteja utilizando mais de um adaptador de rede.

#Capturar o adaptador de rede
$NetAdapter = Get-NetAdapter

#Renomear para facilitar identificação
$NetAdapter | Rename-NetAdapter -NewName "LAN_NIC"

#Atribuir novo IP ao adaptador de rede
New-NetIPAddress -InterfaceIndex $NetAdapter.ifIndex `
   -AddressFamily "IPv4" `
   -IPAddress "11.1.1.1" `
   -PrefixLength "24" `
   -DefaultGateway "11.1.1.1"

Como esta máquina será também o DNS Server, podemos configurar o endereço do DNS como um loopback para própria máquina.

#Configurar o endereço do DNS
Set-DnsClientServerAddress -InterfaceIndex $NetAdapter.ifIndex -ServerAddresses "127.0.0.1"

Antes de começarmos a configurar nossa floresta, é interessante renomear esta máquina para algo mais amigável como “WS2016-DC”.

#Renomear a máquina
Rename-Computer -NewName "WS2016-DC" -Restart

Com a flag “Restart” habilitada, sua VM terá seu nome alterado e será reiniciada. Então, podemos partir para a instalação de algumas features.

#Importar módulo
Import-Module ServerManager

#Instalar o pacotão Domain Controller
Install-WindowsFeature AD-Domain-Services -IncludeAllSubFeature -IncludeManagementTools
Install-WindowsFeature DNS -IncludeAllSubFeature -IncludeManagementTools
Install-WindowsFeature GPMC -IncludeAllSubFeature -IncludeManagementTools

Com esses comandos, estamos instalando o “Active Directory Domain Services”, o “Domain Name System” e o “Group Policy Management Console”. Esse é o pacotão básico de um Domain Controller. As flags “IncludeAllSubFeature” e “IncludeManagementTools” são usadas para instalar o pacote completo com ferramentas de administração remota (RSAT), módulo de powershell específicos, etc.

Finalmente, iremos instalar nossa floresta. Neste momento, estamos criando o domínio “SQLNET.com”, configurando o DNS e promovendo esta VM à Domain Controller. Estou utilizando o “Read-Host” apenas para solicitar a senha previamente. Você também poderia digitá-la quando o cmdlet “Install-ADDSForest” solicitasse. Este último cmdlet possui diversas flags e nuances, por isso sugiro que em caso de dúvidas olhe na documentação oficial [1].

#Recuperar senha de Administrador de Domínio
$Password = Read-Host -AsSecureString -Prompt "Digite sua senha:"

#Importar módulo
Import-Module ADDSDeployment

#Instalar nova floresta
Install-ADDSForest  -DomainName "SQLNET.com" `
   -SafeModeAdministratorPassword $Password

Nota: Quando o nome NETBIOS não é fornecido, ele é determinado automaticamente como o primeiro nome do domínio. Ele também deve possuir 15 ou menos caracteres, se não a instalação falhará.

Executando esses comandos, sua VM será reiniciada mais uma vez. No entanto, a partir deste momento, você deverá utilizar o login do administrador de domínio para logar. No meu caso, o login é “SQLNET\Administrator”.

INDO UM PASSO ALÉM

Agora que já temos o DC pronto, podemos configurar o DNS reverso. Desta forma, podemos obter um nome quando perguntarmos através de um IP (i.e. “ping –a 11.1.1.1”). Iremos criar uma zona de lookup reverso para a rede “11.1.1.0/24”, ou seja, abordaremos todas as máquinas com endereço IP “11.1.1.x” no nosso domínio.

#Criar a zona de lookup reverso
Add-DnsServerPrimaryZone -NetworkID "11.1.1.0/24" `
-ReplicationScope "Domain" `
-DynamicUpdate "Secure"

Outra necessidade comum é a criação de um usuário de domínio. Como exemplo, vou criar um usuário para a conta de serviço do SQL Server chamada “svc_sqlservice”.

#Recuperar senha
$Password = Read-Host -AsSecureString -Prompt "Digite sua senha:"

#Cria novo usuário
New-ADUser -Name "svc_sqlservice" `
-Enabled $true `
-AccountPassword $Password 

Como todos os cmdlets que usei, este último possui diversas opções e flags que você encontra aqui [2]. Basta ajustar de acordo com as necessidades do seu lab.

LINKS

[1] https://technet.microsoft.com/en-us/library/hh974720.aspx

[2] https://technet.microsoft.com/en-us/library/ee617253.aspx