Blog

Disaster Recovery

16 de Março, 2010

A imagem diz tudo, na grande maioria dos casos. Hoje fizemos uma simulação de falha num servidor de alojamento. O procedimento em si, deu para testar a nossa preparação para repor os serviços em caso de falha.

O servidor escolhido para ser reposto, é um Quad Core, 8 GB RAM, 2 x discos (hotswap) de 1 TB em RAID1, com o sistema Operativo Linux (CentOS 5) e o painel de controlo cPanel, e aloja cerca de 250 contas de alojamento da Efeito.net. Esta é uma configuração quase que padrão para os servidores de Alojamento da Efeito.net.

Além do RAID, standard em todos os servidores utilizados para alojamento, são feitos diáriamente backups com a ferramenta da cPanel para um terceiro disco no mesmo servidor, e ainda temos activos em todos os servidores, o sistema de Continuous Data Protection da R1SOFT. Este sistema, permite-nos ter backups integrais do servidor, e repor rapidamente um ficheiro apenas, ou fazer um “Bare Metal Restore” de todo o servidor em caso de falha grave (por exemplo, caso de falha dos 2 discos, ou até mesmo de sistema operativo comprometido), com até 10 pontos de restauro.

Temos hardware suplente preparado para ser usado, sem haver a necessidade de estar a analisar problemas de hardware com o servidor em offline. O procedimento estabelecido em caso de falha de hardware de um servidor é simples, tirar os discos, colocar noutro barebone com as mesmas características, arrancar o novo, e verificar posteriormente quais os problemas que o outro servidor tinha. Isto sem haver grandes downtimes.

A simulação de hoje, pegamos num servidor suplente, arrancamos o servidor com o CD  de recuperação da R1SOFT, efectuamos o Bare Metal Restore, e passado 1:30  aproximadamente, o servidor encontrava-se totalmente reposto.

Conclusão. Mesmo com uma falha grave (neste caso foi mesmo como se o servidor tivesse deixado de existir) conseguiu-se repor um servidor idêntico, com o backup da noite anterior, em menos de 2 horas de downtime.

Bookmark and Share

Migrar VPS OpenVZ entre Hosts

13 de Março, 2010

A tecnologia OpenVZ permite-nos criar e gerir facilmente VPS linux. Tanto na aqui, como aqui, temos disponíveis planos de VPS que permitem aos clientes, terem um acesso root, e personalizar as suas instalações como pretendem, usando a distribuição com que estão mais confortáveis, seja ela CentOS, Fedora, Debian, Ubuntu, ou outras.

É possível migrar os containers, entre servidores distintos desde que estes usem a mesma tecnologia (OpenVZ) e que seja possível o acesso SSH entre eles.

Para migrar containers, o primeiro passo, e que não tem a ver com o openvz em si, é configurar o acesso do servidor antigo ao novo, sem ser necessário password. Isso é simples, usando ssh keys. Ultrapassada essa fase (ou seja, fazendo ssh servidor_novo a partir do antigo, e ele ligar-se directamente sem pedir password), basta usar o vzmigrate. É possível até fazer a migração sem grande downtime, usando o comando


vzmigrate --online 10.0.0.1 120

Em que 10.0.0.1 é o IP do servidor de destino, e 120 é o ID do container. O que deverão obter é algo como:


OPT:--online
OPT:10.0.0.2
Starting online migration of CT 120 to 10.0.0.1
Preparing remote node
Initializing remote quota
Syncing private
Live migrating container...
Syncing 2nd level quota
Cleanup

E pronto, se fizermos “vzlist -a” no servidor antigo, veremos que o container já não está lá. E o mesmo comando no servidor novo, mostra-nos o container a correr. Se durante o processo pingar-mos o IP do container, o downtime é praticamente nulo.

De qualquer das formas, se não se sentir confortável em realizar estas operações, o nosso apoio técnico está disponível para as fazer.

Bookmark and Share

Como alterar o ID de um container em OpenVZ

2 de Março, 2010

Há várias formas de chegar à mesma solução, mas as publicadas aqui são testadas por nós, e testadas antes de serem aplicadas.

Quem utiliza virtualização com OpenVZ, de certeza que já precisou de migrar containers entre hosts físicos, o problema é quando o container que vamos migrar tem um ID que já existe no host de destino. Vamos supor, que temos um container com o ID 100 e queremos alterá-lo para 200.

1º Passo – Criar um ponto de restauro (para a directoria /tmp)
vzctl chkpnt 100 --dumpfile /tmp/bkp.100

Ao fazermos este procedimento, a VPS neste momento deve estar parada. Podemos verificar o estado com
vzlist -a

2º Passo – Renomear os ficheiros de configuração e conteúdos da VPS
mv /etc/vz/conf/100.conf /etc/vz/conf/200.conf
mv /vz/private/100 /vz/private/200
mv /vz/root/100 /vz/root/200

3º Passo – Editar o ficheiro de configuração
Editar com o vi por exemplo, o ficheiro de configuração, e alterar onde diz /vz/private/100 para /vz/private/200
vi /etc/vz/conf/200.conf

4º Passo – Restaurar a VPS
vzctl restore 200 --dumpfile /tmp/bkp.100

E pronto, se executarmos “vzlist -a” a VPS já está a correr, e com o novo ID.

Bookmark and Share

wlconnect connecting your business

26 de Janeiro, 2010

Abriu finalmente hoje o site wlconnect.pt!

Dedicado a apresentar e promover os serviços de datacenter da Weblevel. Lá podem encontrar mais informações sobre servidores dedicados, servidores virtuais, housing, soluções de backups, serviços de assistência entre outros.

Visite já o site www.wlconnect.pt e fique a conhecer esta nova oferta.

Bookmark and Share

Activar acesso SSH no VMware ESXi

22 de Janeiro, 2010

Por diversos motivos, é necessário por vezes o acesso por SSH aos servidores com ESXi. Para o activar é relativamente simples, mas cuidado ao fazê-lo. A própria VMWARE desaconselha que seja feito, a não ser que saibam o que estão a fazer, com segurança.

1. No terminal carregar em ALT+F1 para abrir uma consola
2. Escrever unsupported na janela que se abre, e carregar ENTER
3. Aparece um ecran que pede a password, colocar a password, e novamente ENTER
4. Editar o ficheiro inetd.conf (vi /etc/inetd.conf)
5. Na linha que começa por # SSH, retirar o #
6. Gravar o ficheiro
7. Matar o processo inetd ( executar primeiro “ps | grep inetd” para saber qual o PID do processo, e depois “kill -HUP _PID_” )

E pronto, já conseguem aceder por SSH.

You have activated Tech Support Mode.
The time and date of this activation have been sent to the system logs.

Tech Support Mode is not supported unless used in consultation
with VMware Tech Support.

Bookmark and Share
« Newer PostsOlder Posts »