Hoje iremos falar de uma arquitetura para RDS em Oracle Cloud usando o FSlogix como armazenamento de perfis

Recentemente nesse blog, criamos um artigo ensinando a configurar o FSLogix em um ambiente Microsoft com discos anexados localmente. Ele pode ser acessado aqui

Porém quando falamos de nuvem e ambientes produtivos, não podemos deixar de pensar na resiliência e alta disponibilidade, a Microsoft tem diversos modelos e arquiteturas de referência que auxilia nesse processo, mas como estamos em um ambiente que será criado em Oracle Cloud, irei usar uma “carta na manga”.

Essa tal “carta na manga” será a configuração de armazenamento de profiles em mais de 1 diretório de dados, no nosso caso Instâncias Windows em OCI usando o contexto de Cache Local nas instâncias que serão acessadas remotamente.

E o porque vamos usar isso ao invés de uma solução de Storage Centralizado (FSS)?

Bom essa é uma pergunta boa e acredito que vocês vão fazer. Ela é muito importante nesse cenário e a resposta é Custo.

Nas documentações da Microsoft, se você olhar o contexto de arquiteturas de referência para utilização desse recurso, todas vão apontar para o uso de Azure Files ou NetApp Files, isso porque essas soluções de armazenamento conseguem entregar compartilhamentos SMB para as instâncias, diretamente, sem necessitar de um intermediário.

Em Oracle, você pode usar algo parecido, como o serviço de File Storage, ele vai entregar resiliência pois tem um SLA de 11 (onze) 9’s (noves) 9,9999999999% de disponibilidade, porém o custo por Giga do recurso é um pouco elevado, nesse caso pode se tornar inviável financeiramente.

Como boa prática você deve sempre avaliar se o custo x benefício x necessidade da solução atender da melhor forma o seu cenário e sim, usar o File Storage como sua camada de Storage em Oracle Cloud pode ser a melhor opção.

Vou deixar abaixo algumas documentações sobre o FSLogix da Microsoft, é importante para que você entenda como você pode usar os modelos de alta disponibilidade e também algumas referências técnicas.

• Opções de alta disponibilidade ou resiliência de contêiner usando o Cache de Nuvem – FSLogix | Microsoft Learn
• Opções de armazenamento de contêiner – FSLogix | Microsoft Learn

Não esqueça também que o FSLogix tem alguns requisitos de Sistemas Operacionais e Licenciamentos que devem ser levados em consideração, abaixo você pode consultar tudo.

• Pré-requisitos para FSLogix – FSLogix | Microsoft Learn

Terminadas as considerações, vamos ao que interessa.

Nesse artigo, por mais que tenhamos já criado previamente um artigo anterior sobre FSLogix, vou abordar do zero, principalmente pois alguns conceitos de configuração base são alterados, e é importante explicar cada um deles.

Passo 1: Configurado nossos Hosts de Armazenamento.

A primeira etapa consiste em você criar 2 ou mais instâncias Windows Server, anexar discos secundários nas instâncias e colocar no domínio.

Considere criar volumes de armazenamento que possam alocar os profiles, faça uma análise prévia (Tamanho de Perfis de Usuário x Quantidade de Usuários), com isso você vai conseguir dimensionar quanto de disco cada instância de Perfis terá anexada.

Feito isso, apresente dos discos no sistema Operacional, aqui vai uma dica de ouro, se você estiver em um ambiente que precisa de muito IOPs, considere criar uma instância com a capacidade de oCPU que atenda requisitos para sua performance, a Oracle tem um conceito interessante que entrega IOPs em Ultra High Performance e você pode verificar nesses links abaixo, para entender o contexto e dimensionar o IOPs ideal.

• Formas de VM para iSCSI e Volumes Anexados Paravirtualizados
• Detalhes de Desempenho das Formas
• Calculando o Desempenho do Volume
• Unidades de Desempenho de Volumes

E porque considerar o o IOPs?

A documentação da Microsoft tem uma consideração que auxilia como base para dimensionar o IOPs por usuário e pode ser consultada aqui, ou seja (Quantidade de Usuários X IOPS de criação contínua) + (Quantidade de Usuários X IOPS de entrada/saída)

• Opções de armazenamento de contêiner – FSLogix | Microsoft Learn

Após dimensionar o disco, entender o quanto de VPU será o ideal, você deve apresentar os discos ao sistema Operacional, após apresentar, em cada instância aplique as ACLs usando as boas recomendações abaixo.

Você também pode aplicar as ACLs usando o icacls

icacls \\contosoanf-1408.contoso.com\fsl-profiles /inheritance:r
icacls \\contosoanf-1408.contoso.com\fsl-profiles /grant:r "CREATOR OWNER":(OI)(CI)(IO)(M)
icacls \\contosoanf-1408.contoso.com\fsl-profiles /grant:r "CONTOSO\Domain Admins":(OI)(CI)(F)
icacls \\contosoanf-1408.contoso.com\fsl-profiles /grant:r "CONTOSO\Domain Users":(M)

Altere o Domain Users para o grupo de usuários específico se esse for o seu caso.

Faça isso em todos os discos de todas as instâncias que farão parte do grupo de armazenamento de Profiles

Passo X: Considerações sobre arquitetura (RDS e FSLogix)

Antes de irmos para o Passo 2, criei um Passo X para explicar um pouco o contexto da solução.

Essa etapa é a mais importante e que terá algumas considerações relevantes para o processo.

Vou explicar baseada na imagem abaixo, um exemplo simples da arquitetura que será utilizada que irá refletir como será implementando.

O que nós temos na imagem acima:

1 – São os servidores de RDS, onde os usuários irão acessar. Neles teremos que instalar o aplicativo do FSLogix e também aplicar as configurações de registro relacionados ao FSLogix, as configurações de registro podem ser realizadas localmente através de scripts ou via GPO, importante que o FSLogix esteja instalado previamente e a instância já tenha sido reiniciada antes de criar as chaves de registro ou aplicar as GPOs.

2 – Como iremos usar o modelo de Cloud Cache, teremos um disco secundário em cada instância de RDS. Esse disco será responsável por armazenar, temporariamente, os perfis de usuários localmente e sincronizará com os servidores de FSLogix. Essa configuração garante mais disponibilidade para a infraestrutura.

3 – Servidores de FSLogix serão responsaveis por armazenar os Profiles dos usuários.

4 – Os discos locais de cada servidor de FSLogix terão todos os profiles armazenados em uma unidade secundária.

O que deve ser considerado:

• Discos de FSLogix (Considere ter armazenamento disponível para armazenar todos os profiles dos usuários que fazem parte do seu pool de RDS)
• Discos de RDS (Considere ter em cada instância um disco adicional com a quantidade de espaço suficiente para armazenar os profiles dos usuários que irão conectar localmente, ele não precisa ser do tamanho dos discos do FSLogix, pois iremos configurar uma regra de deletar após a sincronização final, ou seja, ele sempre será limpo e seu tamanho tende a ser reduzido)
• Servidores de RDS, considere o necessário de computação para execução das aplicações de usuários
• Servidores de FSLogix: Não existe uma documentação oficial sobre o quanto de vCPU e Memória é necessário, pois em um modelo tradicional o servidor não faz parte desse escopo, mas se quiser uma estimativa, pense para cada 10 ou 15 usuários 1vCPU e para Memória, se for um ambiente leve, sem muito dado em profile de 200MB a 300MB por usuário e caso tenha Outlook, Teams ou itens de profile que devem carregar, pense entre 500MB a 600MB por usuário de memória para o dimensionamento dos servidores de FSLogix, vale ressaltar que isso é uma estimativa, pode depender também de outras variáveis como antivírus, inspeção e rede.

Em resumo, como será o fluxo da solução:

Usuário faz logon:

• FSLogix monta o VHDX no cache local (ex: D:\FSLogixCache) da máquina.

O cache local é sincronizado com:

• \\servidor1\Perfis\%username%
• \\servidor2\Perfis\%username%

Durante a sessão:

• A leitura/gravação do perfil ocorre no cache local;
• FSLogix mantém os dois servidores remotos atualizados automaticamente.

Se o servidor1 ou servidor2 falhar:

• Nada muda — o usuário continua usando o cache local;
• Quando o servidor voltar, a sincronização será retomada.

Ao fazer logoff:

• O cache sincroniza as últimas alterações com os servidores;
• (Opcional) Você pode limpar o cache com script, políticas ou regras no registro do FSLogix.

Benefícios:

• Alta performance: uso intenso de disco local, menos I/O de rede;
• Alta disponibilidade: múltiplos destinos remotos;
• Resiliência: o logon/sessão não quebra se um storage estiver fora.

Passo 2: Configurando o FSLogix nos Servidores de RDS

Depois de uma pequena pausa para explicar o contexto no Passo X, vamos a mão na massa, eu sou meio suspeito de falar que é a parte que mais gosto pois eu escrevo bastante, ou seja, gosto de escrever também😂.

Entendendo que você já tem seus servidores RDS no domínio, configurados e já está com todo o processo de licenciamento prévio para sessões já organizados, vamos começar o trabalho neles.

A primeira coisa é você entender quantos usuários por instância de RDS irão se conectar, depois entenda qual será o tamanho máximo de perfil que irá disponibilizar para cada usuário.

Como exemplo, vou imaginar que irei ter no máximo 10 usuários por RDS e cada usuário não terá um profile maior que 10GB, esse será o limite, com isso eu já sei que meu disco para profile local terá que ser de 100GB no mínimo.

Como em tecnologia, trabalhar no limite não é uma boa prática, considere uma “gordurinha”, eu no meu caso irei considerar uma folga de segurança de inicialmente 20%, ou seja, vou ter um disco total em cada instancia de 120GB

• 10 Usuários
• 10GB por Usuário
• 20% de Margem de Segurança

= Disco local de Cache de 120GB

📝Aplique as mesmas regras de permissionamento (ACLs) no disco local, ele não precisa ser compartilhado.

Após configurar o disco, instale o FSLogix no servidor de RDS

Faça o download do FSLogix no oficial da Microsoft: https://aka.ms/fslogix/download

Extraia os arquivos e instale o FSLogixAppsSetup.exe

Após instalar reinicie a instância

Quando ela iniciar, acesse a instância e execute as seguintes alterações no registro, a imagem a seguir irá explicar cada campo, para seu cenário, faça os ajustes necessários baseados no seu ambiente nos seguintes valores:

$CCDLocations = “\\Servidor1\Profiles”, “\\Servidor2\Profiles” : Altere\\ServidorX\Profiles com os dados do seu ambiente

CloudCacheCleanupThresholdDays: Número de dias que um VHD(x) de cache local fica antes de ser apagado, na teoria isso nem será necessário, pois iremos criar um registro para limpar após logoff, mas é bom ter como uma segunda opção caso o perfil fique alocado mesmo depois do logoff.

SizeInMBs: Tamanho máximo do container de perfil (VHDX)

Atualize tambem o Path do seu CacheDirectory, alterando o P:\FSLogixCache com o seu caminho local: Set-ItemProperty -Path “Registry::HKLM\SYSTEM\CurrentControlSet\Services\frxccd\Parameters” -Name “CacheDirectory” -Value “P:\FSLogixCache” -Force

$CCDLocations = @(
    "type=smb,name=`"SMB Provider 1`",connectionString=\\Servidor1\Profiles",
    "type=smb,name=`"SMB Provider 2`",connectionString=\\Servidor2\Profiles"
)

# Parâmetros principais do FSLogix
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name Enabled -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name DeleteLocalProfileWhenVHDShouldApply -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name FlipFlopProfileDirectoryName -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name LockedRetryCount -PropertyType dword -Value 3 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name LockedRetryInterval -PropertyType dword -Value 15 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name ProfileType -PropertyType dword -Value 0 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name ReAttachIntervalSeconds -PropertyType dword -Value 15 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name ReAttachRetryCount -PropertyType dword -Value 3 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name SizeInMBs -PropertyType dword -Value 10000 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name VolumeType -PropertyType string -Value "vhdx" -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name PreventLoginWithTempProfile -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name IsDynamic -PropertyType dword -Value 1 -Force


# Cloud Cache específico
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name CCDLocations -PropertyType MultiString -Value $CCDLocations -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name CloudCacheCleanupThresholdDays -PropertyType dword -Value 1 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name ClearCacheOnLogoff -PropertyType dword -Value 1 -Force

#Parametros de Timeour e Melhoria
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name CloudCacheTimeoutSeconds -PropertyType dword -Value 60 -Force
New-ItemProperty -Path HKLM:\SOFTWARE\FSLogix\Profiles\ -Name CloudCacheFailureTolerance -PropertyType dword -Value 3 -Force

# Atualizando o local de Cache para a Unidade secundária
Set-ItemProperty -Path "Registry::HKLM\SYSTEM\CurrentControlSet\Services\frxccd\Parameters" -Name "CacheDirectory" -Value "P:\FSLogixCache" -Force

Após aplicar, faça Logoff e autentique novamente com uma conta de rede, de preferência de um usuário final para validação

O comportamento esperado é o seguinte:

No disco secundário das instâncias de RDS, ele irá criar os Profiles em Cache conforme imagem abaixo:

Também deve criar os mesmos profiles nos servidores de FSLogix, no meu caso por exemplo tenho 2

Como eles estão centralizados, quando eu fizer logon com o usuário ele cria o perfil localmente na unidade secundária e quando eu fizer logoff ele apaga o profile localmente, mas mantem nas servidores de FSLogix

Com isso, mesmo que 1 dos nós caiam durante minha sessão aberta, eu continuo normalmente usando e autenticando devido o profile com Cache local e quando ele retornar, a sincronização é atualizada para o nó faltante

Importante: Pelo menos 1 nó de FSLogix deve estar Operacional dentro de sua infraestrutura.

Nesse exemplo 1 nó está fora.

Mas mesmo assim consigo autenticar e trabalhar no meu host RDS

Espero que esse artigo tenha sido útil e qualquer dúvida estou a disposição.