Este artigo tem o objetivo de demonstrar a ativação do TS e algumas opções basicas de segurança.
Este artigo tem o objetivo de demonstrar a ativação do TS e algumas opções basicas de segurança.
Olá Pessoal, hoje vou fazer um breve tutorial explicando como criar um repositório ISO local no Xen Server para instalação de VM utilizando a imagem localmente, isso facilita a instalação e não necessita de acesso a internet.
Bem vamos lá:
Primeira mente autentique-se no SSH e então execute:
mkdir -p /var/opt/xen/iso_import
Pronto, criamos a pasta onde serão inseridas as imagens, após execute:
xe sr-create name-label=ISOs type=iso device-config:location= /var/opt/xen/iso_import device-config:legacy_mode=true content-type=iso
Em seguida:
xe-mount-iso-sr /var/opt/xen/iso_import
Este comando irá então montar a pasta como repositório de arquivos.
Pronto, agora basta inserir as imagens (isos) dentro da pasta: /var/opt/xen/iso_import
Ao concluir todo esse procedimento, imediatamente já será inserido no Xen Center o Storange ISOs como mostra a figura abaixo:
E também no processo de instalação de um novo VM, também ira aparecer as suas imagens na lista de ISSO Image:

Pronto, agora você já pode instalar VMs utilizando a imagem do OS,
Bem é isso, em breve novos tutoriais !
Temos algumas formas para fazer uma migração de um servidor executando o Windows Server 2003 R2 para Windows Server 2008 R2 com o Active Directory instalado, porém algumas recomendações:
1) Se for migrar de 2003 R2 para 2008 R2 usando o mesmo servidor (in place) só será possível se o Windows Server 2003 R2 for 64 bits, uma vez que o Windows Server 2008 R2 só vem com suporte a X64.
2) Se o Windows Server 2003 R2 for 32 bits só será possível migrar para o Windows Server 2008 R2 usando um novo servidor.
3) É importante também cuidar o idioma dos Sistemas Operacionais.
4) Recomendamos ainda verificar toda a compatibilidade de hardware e software antes de começar sua migração.
5) Não esqueça de fazer os devidos backups.
Migrando Windows Server 2003 R2 32 Bits para Windows Server 2008 ( In Place)
Neste exemplo vamos usar o DVD do Windows Server (não R2) devido a compatibilidade de arquitetura 64 e 32, mas lembramos que o processo é idêntico)
1) Insira o DVD do Windows Server 2008 no servidor com o Windows Server 2003 R2 > clique em Instalar agora
2) Clique em Conectar para obter as atualizações mais recentes para instalação
3) Selecione a versão do Windows a ser instalado > Avançar
4) Aceite os Termos > Avançar
5) Selecione Atualização
6) Checando a compatibilidade
7) Avançar
Agora é só aguardar ( Deve levar horas)
9) Ao finalizar a instalação, abra o console do seu Active Directory e toda sua estrutura estará OK. Verifique também as GPOs e faça os testes já conhecidos em cima do seu AD.
Migrando Windows Server 2003 R2 32 Bits para Windows Server 2008 R2 usando dois servidores
Para realizar este processo, temos alguns novos requisitos, além dos já citados no início deste tópico.
Vamos aos novos requisitos:
1) Em um servidor temos o Windows Server 2003 R2 (32 bits) e no novo servidor, o Windows Server 2008 R2 que só temos em 64 bits.
2) Temos o Active Directory instalado somente no servidor com o Windows Server 2003 R2.
3) Com o Windows Server 2008 R2 já instalado no Servidor novo, ingresse este no domínio do Windows Server 2003 R2.
No servidor Windows Server 2003 R2 execute os seguintes passos:
1) Acesse o console do Active Directory > clique com o botão direito do mouse sobre Aumentar nível funcional do domínio…
2) Selecione Windows Server 2003 > clique em Aumentar
3) Nível aumentado.
4) Vamos agora preparar o Domínio para receber o primeiro Domain Controller Windows Server 2003.
Insira o DVD do Windows Server 2008 R2 > no diretório Support > acesse o diretório adprep > execute os seguintes comandos:
adprep.32.exe /forestprep
2) Pressione C > ENTER
3) Processo em execução
4) Processo finalizado.
5) Execute
adprep.32.exe /domainprep
6) Processo finalizado.
7) Execute
adprep.32.exe /rodcprep
Execute
adprep.32.exe /domainprep /gpprep
Replicando o Active Directory do Windows Server 2003 R2 para o
Windows Server 2008 R2
Como você já deve ter percebido, todos os usuários serão autenticados pelo servidor com o Active Directory.
Esta centralização do Active Directory em um único servidor pode nos dar muito problema, uma vez que o nosso servidor do Active Directory sofra uma pane, todos os nossos usuários que autenticam nele ficarão sem acesso.
Para prevenir este possível problema você pode configurar outro servidor como Controlador de domínio adicional.
Para aplicar todo este recurso temos algumas dicas inicias:
1) Ingresse o servidor réplica do domínio principal (não esqueça que o DNS primário deverá ser o IP do seu servidor DNS local)
2) Servidor réplica ingressado ao domínio.
3) Após ingressar o Servidor réplica ao AD, ele irá aparecer no contêiner Computers.
4) Para iniciar a instalação do AD réplica > executar > dcpromo.exe
5) Marque Usar a instalação em modo avançado > Avançar
6) Clique em Avançar.
7) Como já temos uma floresta > marque Floresta existente > Adicionar um controlador de domínio a um existente > Avançar.
Automaticamente o domínio será localizado > clique em Definir e entre com as credenciais do usuário Administrador do domínio > clique em Avançar.
9) Clique em Avançar
10) Clique em Avançar
11) Um catálogo global é um controlador de domínio que armazena uma cópia de todos os objetos do Active Directory em uma floresta. O catálogo global armazena uma cópia completa de todos os objetos no diretório para seu domínio host e uma cópia parcial de todos os objetos para todos os outros domínios na floresta, conforme mostrado na figura a seguir.
Marque Catálogo Global > Avançar.
12) Selecione Replicar dados pela rede de um controlador de domínio existente > Avançar.
13) Selecione o Controlador de domínio > Avançar
14) Selecione um local para o banco de dados, log e SYSVOL > Avançar.
15) Informe uma senha para restauração > Avançar.
16) Clique em Avançar.
17) Replicando dados.
18) Clique em Concluir.
19) Console do Active Directory no Server 2003 (principal)
GPOs no Server 2003
20) Console do Active Directory no Server 2008 R2
GPOs Server 2008 R2
Instalando ferramentas de suporte no Windows Server 2003 R2
1) Ainda no Servidor Windows Server 2003 R2 > insira o CD de instalação do Windows Server 2003 R2 > na pasta Support\Tools > execute o arquivo SUPTOOLS.MSI para instalar algumas ferramentas.
2) Ferramentas já instaladas > acesse Windows Support Tools > Command Prompt
3) Vamos agora através do comando netdom query fsmo verificar nosso schema. Observe que todas as funções fazer parte do server2003.
4) No servidor Windows Server 2003 R2 vamos então transferir todas as funções mostradas na figura acima para o novo servidor executando o Windows Server 2008 R2.
Transferindo funções:
Vamos agora transferir as 5 regras de operações do Active Directory, essas regras também são conhecidas como FSMO Rules (Flexible Single Master Operation). Essas regras são essenciais para a saúde do AD e o bom funcionamento do AD.
Nosso objetivo é transferir essas 5 regras para o controlador de domínio Windows Server 2008 R2.
Primeiro vamos listar as 5 regras de descobrir qual os controladores de domínio tem propriedade sobre elas para isso vamos executar o comando NETDOM QUERY FSMO.
O utilitário NETDOM já foi instalado quando colocamos as ferramentas de suporte no tópico já apresentado.
Vamos agora utilizar o utilitário NTDSUTIL que é uma ferramenta de administração avançada do Active Directory para realizar a transferência.
a) Acesse Menu Iniciar > Windows Support Tools > Command Prompt
Execute os seguintes comandos:
1) ntdsutil
2) roles
3) connections
4) connect to server server2008 ( onde server2008 é o hostname do seu servidor 2008)
5) q
6) transfer schema master
7) Confirme SIM
b) Digite:
1) transfer PDC
2) Confirme SIM
c) Digite:
1) transfer domain naming master
2) Confirme SIM
d) Digite:
1) transfer RID master
2) Confirme SIM
e) Digite:
1) transfer infrastructure master
2) Confirme SIM
13) Execute netdom query fsmo > para verificar que foram transferidas todas as funções para o servidor Windows Server 2008 R2.
Rebaixando o AD do Windows server 2003 R2
1) Execute:
2) Avançar
3) Não marque a opção “Este servidor é o último controlador de domínio no domínio” > Avançar
4) Digite uma nova senha para o Administrador local do Servidor 2003 > Avançar
5) Avançar
6) Removendo
7) AD removido > Concluir.
Console do AD no Windows Server 2008 R2, observe que agora o SERVER2003 não é mais membro de Domain Controller mas de Computers.
Em vez de montar um único servidor com componentes redundantes, existe também a opção de usar um cluster de alta disponibilidade (chamados de “high-availability clusters” ou “failover clusters”), onde são usados dois servidores completos, onde a única função do segundo servidor é assumir a posição do primeiro em caso de falhas (modo chamado de ativo/passivo), diferente de um cluster com balanceamento de carga, onde os servidores dividem as requisições (ativo/ativo).
Existem diversas soluções para clusters de alta disponibilidade. Entre as soluções abertas, uma das mais usadas é o projeto Linux-HA (High-Availability Linux, disponível no http://www.linux-ha.org), que desenvolve o heartbeat, um daemon responsável por monitorar o status dos servidores do cluster e permitir que o segundo servidor assuma as funções do primeiro em caso de pane.
Cada um dos servidores possui pelo menos duas placas de rede, o que permite que eles sejam simultaneamente ligados à rede e ligados entre si através de um cabo cross-over ou de um switch dedicado. A conexão interna é usada pelo heartbeat para as funções de monitoramento e sincronismo dos processos, de forma que o segundo servidor possa assumir imediatamente a função do primeiro quando necessário, assumindo o endereço IP anteriormente usado por ele.
É comum também o uso de uma terceira interface de rede em cada servidor (ligada a um switch separado), destinada a oferecer uma conexão de backup com a rede. Isso permite eliminar mais um possível ponto de falha, afinal, de nada adianta ter servidores redundantes se o switch que os liga à rede parar de funcionar.
Em geral, o heartbeat é usado em conjunto com o Drbd (http://www.drbd.org), que assume a função de manter os HDs dos dois servidores sincronizados, como uma espécie de RAID 1 via rede. Ao usar o Drbd, o HD do segundo servidor assume o papel de unidade secundária e é atualizado em relação ao do primeiro em tempo real. Quando o primeiro servidor pára, a unidade de armazenamento do segundo servidor passa a ser usada como unidade primária. Quando o servidor principal retorna, o HD é sincronizado em relação ao secundário e só então ele reassume suas funções.
Outra opção é utilizar uma SAN (veja a seguir) para que os dois servidores compartilhem a mesma unidade de armazenamento. Nesse caso, não é necessário manter o sincronismo, já que os dados são armazenados em uma unidade comum aos dois servidores.
Como pode ver, adicionar componentes redundantes, sejam fontes, HDs ou servidores adicionais aumentam consideravelmente os custos. A principal questão é avaliar se o prejuízo de ter o servidor fora do ar por algumas horas ou dias durante as manutenções, acidentes e imprevistos em geral é maior ou menor do que o investimento necessário.
Um pequeno servidor de rede local, que atende a meia dúzia de usuários em um pequeno escritório dificilmente precisaria de redundância, mas um servidor de missão-crítica (como no caso de um banco) com certeza precisa. Cada nível de redundância adiciona um certo valor ao custo dos servidores, mas reduz em certa proporção o tempo de downtime.
A disponibilidade do servidor é genericamente medida em “noves”. Um nove indica uma disponibilidade de 90%, ou seja, uma situação em que o servidor fica fora do ar até 10% do tempo (imagine o caso de uma máquina instável, que precisa ser freqüentemente reiniciada, por exemplo), o que não é admissível na maioria das situações.
Com dois noves temos um servidor que fica disponível 99%, o que seria uma boa marca para um servidor “comum”, sem recursos de redundância. Por outro lado, uma disponibilidade de 99% significa que o servidor pode ficar fora do ar por até 7 horas e 18 minutos por mês (incluindo todas as manutenções, quedas de energia, operações de backup que tornem necessário parar os serviços e assim por diante), o que é tolerável no caso de uma rede local, ou no caso de um servidor que hospeda um site fora da área de comércio eletrônico, mas ainda não é adequado para operações de missão crítica.
Para adicionar mais um nove, atingindo 99.9% de disponibilidade (o famoso “three nines”), não é possível mais contar apenas com a sorte. É necessário começar a pensar nos possíveis pontos de falha e começar a adicionar recursos de redundância. Entram em cena as fontes redundantes, o uso de uma controladora RAID com suporte a hot-swap, uso de um nobreak com boa autonomia para todo o equipamento de rede, de forma que o servidor continue disponível mesmo durante as quedas de luz, e assim por diante. Afinal, 99.9% de disponibilidade significa que o servidor não fica fora do ar por mais de 43 minutos por mês.
No caso de servidores de missão crítica, qualquer interrupção no serviço pode representar um grande prejuízo, como no caso de instituições financeiras e grandes sites de comércio eletrônico. Passa então a fazer sentido investir no uso de um cluster de alta disponibilidade e em links redundantes, de forma a tentar atingir 99.99% de disponibilidade. Esta marca é difícil de atingir, pois significa que o servidor não deve ficar mais do que 4 minutos e meio (em média) fora do ar por mês, incluindo aí tudo o que possa dar errado.
Como sempre, não existe uma fórmula mágica para calcular o ponto ideal (é justamente por isso que existem consultores e analistas), mas é sempre prudente ter pelo menos um nível mínimo de redundância, nem que seja apenas um backup atualizado, que permita restaurar o servidor (usando outra máquina) caso alguma tragédia aconteça.
|
||||||||||||||
Instalação e comandos
|
||||||||||||||
Arquivos de configuração detalhados
|
||||||||||||||
Autenticando na base de dados MySQL e evitando conexões simultâneas
|
||||||||||||||
Checagem e retorno de atributos em banco de dados
|
||||||||||||||
Autenticando na base de dados PostgreSQL, Oracle e outros
|
||||||||||||||
Negando temporariamente o acesso de clientes inadimplentes usando SQL
|
||||||||||||||
Autenticando na base de dados de usuários do sistema
|
||||||||||||||
Testando o servidor radius antes de colocá-lo em produção
|
||||||||||||||
Criando gráficos de monitoramento com MRTG
|
||||||||||||||
Extrato de horas
|
||||||||||||||
Administração de usuários
|
||||||||||||||
Ajuda
|
||||||||||||||