Seleção do sistema de arquivos
Não existem muitas opções a serem escolhidas com o objetivo de atender aos requisitos acima. NFS sobre o TCP e
CacheFs são soluções que não combinam todos os requisitos e não são disponíveis em todas as plataformas necessárias.
DFS poderia ser um escolha melhor, porém a tecnologia não é madura o suficiente para ser utilizada em um ambiente de
produção.
AFS é atualmente a única tecnologia de sistemas de arquivos distribuídos suportada que cobre uma significante porção das
exigências. Algumas das características do AFS que são as razões principais para a sua escolha são:
- Cache de disco local
- Consistência do cache garantida
- Gerenciamento lógico de volumes
- Replicação de dados automatizada
- Dados redundantes disponíveis de forma transparente
- Eficiência superior sobre as ligações WAN
AFS não é a solução perfeita para o uso de um sistema de arquivos global. Existem um número de problemas que foram
encontrados, a maioria dos quais estão sendo trabalhados, e alguns têm introduzido algumas limitações no projeto do ambiente:
- Uma célula global
O protocolo Ubik usado pelo banco de dados do servidor AFS não é escalar o suficiente para permitir a existência de uma
única célula global, cobrindo mais de 30 escritórios interconectados. Isto faz com que se tenha uma célula por construção.
- Distribuição de dados entre células
O AFS oferece um mecanismo de replicação de dados dentro de uma célula, porém não existe nenhum mecanismo de
distribuição destes dados entre diferentes células. Foi desenvolvido um mecanismo de distribuição improvisado internamente.
- Sistemas de backup
O sistema de backup do AFS é muito fraco. Tentativas de se recuperar grandes quantidades de dados têm sido
decepcionantes.
- Nenhuma permissão por arquivos
A semântica de permissão de arquivos muda de forma significativa entre o UFS e o AFS. Enquanto existem mais opções para
a permissão de diretórios, não existe nenhuma permissão para arquivos.
- Célula virtual global
O objetivo de uma única e global visão do sistema de arquivos compartilhados é ainda possível, mesmo dentro das limitações
da tecnologia fornecida pelo AFS. Embora a granularidade das células individuais esteja no nível de construção , ela é
escondida da visão do usuário do sistema de arquivos. Usuários irão quase sempre acessar os dados através do espaço de
nomes canônicos, não estando cientes que alguns arquivos vêm das células locais, enquanto outros vêm de células de fora.
% fs lsm /ms/.global/*
‘/ms/.global/bk.a’ is a mount point para o volume ´#a.bk.ms.com:ms.cell’
‘/ms/.global/ln.a’ is a mount point para o volume ´#a.ln.ms.com:ms.cell’
‘/ms/.global/ex.a’ is a mount point para o volume ´#a.ex.ms.com:ms.cell’
‘/ms/.global/mg.a’ is a mount point para o volume ´#a.mg.ms.com:ms.cell’
‘/ms/.global/tk.a’ is a mount point para o volume ´#a.tk.ms.com:ms.cell’
‘/ms/.global/sa.a’ is a mount point para o volume ´#a.sa.ms.com:ms.cell’
figura 1: Pontos de montagem
% ls -al /ms
total 17
drwxr-x 2 afsadmin 2048 Dec 19 1994 .
drwxr-xr-x 16 root 512 Jul 18 03:08 ..
drwxr-xr-x 2 afsadmin 2048 May 13 00:28 .global
drwxr-xr-x 2 afsadmin 2048 Jan 5 1995 .local
drwxr-xr-x 68 afsadmin 4096 Jul 17 13:06 dev
drwxr-xr-x 2 afsadmin 2048 Jul 10 14:31 dist
drwxr-xr-x 4 afsadmin 2048 Jun 22 18:02 group
drwxr-xr-x 29 afsadmin 2048 Jul 5 10:53 user
figura 2: Visão do nível superior
% ls -al /ms/user/w/wpm
lrwxr-xr-x 1 afsadmin 27 Feb 10 10:56 /ms/user/w/wpm -> /ms/.global/sa.a/user/w/wpm
figura 3: Apontador de espaços de nomes globais
O acesso entre as células é fornecido por pontos de montagem para cada célula os quais são coletados através de /ms/.global
(figura 1). Os dois caracterres iniciais fazem referência as localizações, por exemplo tk é Tokio, ln é Londres, etc.
Os pathnames usados por usuários, aplicações, etc, fazem referências ao espaço de nomes canônicos (figura 2). Os quatro
diretórios dev, dist, group e user formam o espaço de nomes canônicos. O diretório home do usuário, isto é, /ms/user/w/wpm, é
somente um ponteiro em direção ao espaço global para a localização real do volume para aquele usuário. (figura 3). Assim, o
diretório home wpm torna-se transparentemente relocável para o diretório home do usuário de célula para célula, sem
necessitar mudanças para o pathname canônico.
A mesma abordagem tem sido usada para o dev (Volumes de Desenvolvimento, isto é, codigo fonte) e grupos (Volumes de Grupos
Compartilhados), e juntas estas 3 classes cobrem todos os dados RW não replicados mantidos no AFS.
A classe final de dados, dados replicados e dados distribuídos, torna-se disponível através de /ms/dist, que consiste em
montar pontos para volumes assumindo estarem sendo obtidos da célula local. O sistema de volumes de distribuição
desenvolvido automatiza a tarefa de replicar os dados entre as células.
Supervisão em tempo real e supervisão batch
Não existem mecanismos de construção para supervisionar o estado dos servidores de arquivos AFS. Para suportar o AFS
em um ambiente de produção é preciso que se gaste uma quantidade significante de tempo desenvolvendo software para
supervisionar o estado do AFS, tanto em tempo real como em batch.
Sistema de gerenciamento de volumes (VMS)
Em um ambiente de múltiplas células é necessária a replicação dos dados entre as células. Foi desenvolvido um sistema para
automatizar a distribuição dos dados e um banco de dados de configuração para manter informações timestamp e
relacionamentos mestre/escravo.
Volumes distribuídos X volumes canônicos
Volume canônico é o volume mestre original para as cópias distribuídas mantidas em cada célula globalmente. Mudanças são
feitas no volume canônico e então, de forma incremental, é realizado o dump/restore para o volume distribuído em cada
célula.
Propagação incremental
A propagação incremental é realizada gerenciando o timestamp em um banco de dados externo para o sistema de arquivos.
O ato de atualizar os volumes em backup ou mover volumes distribuídos de servidor para servidor irá invalidar o timestamp
da última atualização nos próprios volumes. Assim, quando um volume possui uma nova versão para distribuição, o timestamp
de uma cópia do volume canônico é atualizado no banco de dados.
Acesso autenticado para comandos privilegiados
No ambiente Pre-Aurora era fácil delegar permissões para distribuir e manter uma porção da árvore de distribuição para
usuários não-roots, uma vez que rdist não necessita de nenhum privilégio especial de root para distribuir arquivos
de servidor para servidor. O AFS exige privilégios especiais para dump/restore volumes.
É utilizado um mecanismo para determinar a identidade do usuário e, então, é realizada várias operações restritas ao ambiente
do usuário usando a identidade do usuário com chave para procurar operações autorizadas. Este mecanismo permite grupos
de desenvolvimento criarem novos volumes de aplicações AFS para o desenvolvimento de novas versões de uma aplicação
sem a necessidade de intervenção do administrador do sistema.
O objetivo é automatizar todos os procedimentos operacionais para o AFS que necessitam de privilégios administrativos. A
maioria dos processos que são automatizados têm múltiplos passos e muitos são propensos a erros quando realizados por
iniciantes ou até por peritos. VMS automatiza estes passos, reduzindo erros do operador e eliminando a necessidade de dar a
administradores juniors privilégios especiais.
Características WAN
Sistemas de arquivos através de ligações WAN têm historicamente sido evitados devido ao fato de induzir ao pesado uso da
WAN e ao pobre comportamento da tecnologia de sistemas de arquivos (NFS). O uso do AFS sobre a WAN é muito
melhor, devido ao comportamento do protocolo RX sobre cenários de alta transmissão.
Treinamento e suporte
AFS é uma tecnologia radical do ponto de vista de pessoal de suporte. Aprender a gerenciar o sistema de arquivos, depurar e
analisar problemas, etc. necessita a compreensão de um novo conjunto de tecnologias e ferramentas.
Estado corrente do sistema de arquivo global
Existem atualmente 26 construções (células potenciais) globalmente com hosts UNIX de alguma espécie, e no final de 1996
irão existir AFS avaláveis em todos eles. O tamanho destas instalações varia de 3 a 4 hosts até aproximadamente 2000, e
assim a infraestrutura do servidor varia de site para site.
Nas células maiores, foi instalado servidores de arquivos AFS dedicados e servidores de banco de dados. Em células de
tamanho médio , existem servidores realizando funções de servidores de banco de dados ou arquivos. Em sites menores, os
servidores existentes possuem apenas espaço adicional em disco para instalação dos serviços AFS e estes servidores irão
compartilhar a sua funcionalidade com outras CPUs e funções de banco de dados.
Existem atualmente 20GB de dados replicados no AFS, e aproximadamente 200GB de dados do usuário para leitura/escrita
(códigos fonte, diretórios home do usuário e diretórios de grupo). É esperado que a quantidade de dados replicados cresça
regularmente, porém, o crescimento de dados não replicados poderia ser potencialmente explosivo.
Objetivos de Projeto
Qualquer pessoa que tente gerenciar um grande conjunto de sistemas de forma central observa uma absoluta necessidade de
um repositório central de informações de configuração. Isto inclui tradicionais informações de user e de host, mas também
engloba informações da máquina, arquivos de configuração, informações de software e muitas outras. Adicionalmente, a base
de dados de configuração deve prover significante checagem de dependência, para que, por exemplo, um usuário não possa
ser deletado até que todos os grupos e grupos de mail que ele possue também sejam. A base de dados de configuração
global é, virtualmente, parte de cada aspecto do sistema.
Antes de tentar construir um sistema do nada, pesquisou-se o mercado por possíveis soluções. Infelizmente, a maioria dos
produtos visam ambientes nos quais existe apenas um gerenciamento central mínimo, com muitos departamentos querendo
sua própria autonomia. Permitir múltiplos domínios administrativos introduz a possibilidade de mudanças na configuração
local. O objetivo é maximizar a homogeneidade e minimizar configurações locais.
Adicionalmente, era necessário que qualquer sistema a ser utilizado fosse compatível com outros banco de dados
espalhados pela empresa, como o banco de dados de Recursos Humanos e o Inventário. Como já haviam sido construídos
bases de dados como estas no sistema Pré-Aurora, verificou-se que havia experiência e o conhecimento para fazer um
trabalho melhor e construir o banco de dados desejado.
O objetivo do sistema construído, o Distributed System Database (DSDB), foi criar uma base de dados de configuração que
permitisse reconstruir o ambiente físico inteiro com um backup do DSDB. Observa-se que não são dados do usuário, mas
apenas informações de configuração que são armazenadas.
Adicionalmente, não há acesso em tempo real a componentes desta base de dados. Por exemplo, os fontes dos mapas de
NIS são mantidos no DSDB, mas há um processo separado que obtém a informação do DSDB para o NIS. A partir daí, o NIS trata as
consultas em tempo real
No ambiente Pre-Aurora, havia dois bancos de dados que continham informações dos mapas de NIS e da configuração das
máquinas. Contudo, com o crescimento do sistema, descobriu-se alguns grandes problemas com eles:
- Eram sistemas separados que não interagiam.
- Havia pouca checagem de consistência. A checagem que era feita era apenas na hora da entrada de dados. Quando alguém
deletava um usuário, não havia nenhum teste para saber se o usuário estava em outro grupo, mailgroup, etc.
- Por causa do tamanho dos mapas, mudanças levavam mais de uma hora para sair da base de dados e se propagar por
toda a rede.
- Não estavam projetados para suportar escalabilidade.
O DSDB foi projetado para substituir os dois bancos de dados, acrescentar significante funcionalidade e possuía os seguintes objetivos:
- Prover forte checagem de consistência. Não se pode acrescentar objetos que não encaixem dentro de um critério
pré-especificado (por exemplo, não se pode acrescentar uma entrada de host a menos que a rede já exista) e não se pode
deletar um objeto que esteja sendo refenciado (por exemplo, não se pode deletar um host para o qual há
uma entrada fstab na base de dados).
- Interação com outras bases de dados internas.
- Garantir que informações existam em apenas um local.
- Prover completa informação histórica..A informação na base de dados não é nunca deletada, mas, sempre guardada. Usando isto
nós podemos: obter uma visão do ambiente em qualquer ponto do tempo.
- Prover propagação incremental.
- Permitir que todos os dados possam ser lidos internamente por todo o mundo. Não há dados privados na base de dados.
Exemplos de informação de configuração armazenadas na base de dados:
- Informação do arquivo fstab.
- Processos de inicialização quando na máquina é dado o reboot
- Informações de configuração de máquina, como os dispositivos no sistema, os nomes dos sistemas de arquivos montados, etc.
Informação Primária X Secundária
Há dois tipos de informação guardadas no DSDB, primária e secundária. A informação primária é aquela para a qual o
DSDB é a fonte primária, como os dados do passwords e arquivos de host. A informação secundária é aquela para a qual o
DSDB é simplesmente um repositório, como a quantidade de memória na máquina, ou o tipo de graphic card, ou mesmo o
nome real do usuário ( para o qual a base de dados de recursos humanos é a fonte primária).
A informação primária é aquela que é tipicamente entrada manualmente quando um usuário, máquina, serviço etc. é
acrescentado. A informação secundária é aquela que é usualmente carregada em um formato batch automático. Há
auditores noturnos que coletam informações de todas as máquinas e atualizam estas informações na base de dados. Estas
informações permitem criar relatórios de utilização e caracterização do sistema..
Existem um número de programas que pegam informações fora da base de dados. Um destes programas é o atualizador NIS,
que distribui os mapas de NIS incrementalmente. Outro é o programa que atualiza o arquivo fstab de um sistema depois que é
feito o reboot.
Arquitetura
Porque a maioria das bases de dados pre-existentes são feitas em Sybase, o DSDB foi baseado em Sybase também. Todas
as atualizações são feitas através de procedimentos de armazenamento. Estes procedimentos são responsáveis pela forte
checagem de consistência.
Objetivos de projeto
O primeiro objetivo da porção de configuração do OS do Aurora é projetar uma configuração do OS que permita gerenciar
centenas de hosts espalhados pelo globo. A configuração do OS está preocupada apenas com os dados do sistema, não com
os dados associado a, por exemplo, diretórios home dos usuários, partições NFS exportadas ou partições de dados do
Sybase. Foram visados os arquivos que são necessários para executar o sistema principal - aqueles arquivos abaixo do root,
/usr, /var, etc.
Suporte homogêneo para Hardware heterogêneo
Visa-se maximizar a uniformidade das configurações de máquina para simplificar a administração e manter, também,
suporte para múltiplas plataformas de hardware com o objetivo de indicar o hardware certo para o trabalho certo
objetivando, dessa forma, satisfazer as necessidades de uma variedade ampla de aplicações. Do ponto de vista do hardware
e sistema operacional, o sistema deve suportar plataformas de hardware heterogêneas, contudo, o ambiente operacional deve
ser tão uniforme quanto possível através de todas as arquiteturas.
Homogeneidade não é fácil de se obter. Fazer isto em um ambiente heterogêneo é extremamente pesado. Contudo, criar um
ambiente como este oferece grandes benefícios, incluindo economias de escala e a habilidade para permitir que os usuários
possam usar as melhores ferramentas para seu trabalho.
Rapidez, Instalação Automática e Reconfiguração
Hosts deveriam ser facilmente e rapidamente configuráveis. Um mecanismo de instalação que leva duas horas para copiar
dados de um CDROM, e então requer um administrador para atualizar vários files mantidos localmente em um sistema de
backup ou memória, é simplesmente não prático quando instalando centenas de máquinas. Além disto, se uma máquina de
negócio morrer, minutos fazem uma grande diferença. Nossos usuários requisitam a troca dos desktops em menos de 10
minutos.
Control-Alt-Delete
Quando há um problema com o desktop do usuário, não é apropriado sempre levar um tempo para descobrir qual é o
problema. Freqüentemente, tempo é a essência, e os usuários apenas querem retornar On-line tão rápido quanto possível.
Permite-se que o usuário realize o equivalente no UNIX ao control-alt-delete. Se houver um problema de configuração ou de
disco, o usuário em uma SUN, por exemplo, digita L1-A, e então inicializa a rede. A máquina é reinstalada e reinicializada em
menos de 10 minutos, sem nenhuma intervenção do administrador e nenhum requerimento de acesso do root. De fato, no
Aurora leva-se menos tempo para reinstalar um sistema do que leva fsck sua partição de root.
É desencorajado o uso desta facilidade por usuários finais. O administrador do sistema precisa escolher se o problema requer
uma reinicialização e decidir se descobrir a causa do problema é mais importante do que trazer a máquina de volta ao ar
rapidamente.
Suporte para modelos de máquinas
Toda configuração de máquina será tratada através da base de dados de configuração, associando a configuração de um tipo
particular de máquina com um modelo.
Um modelo Sybase pode diferir de um modelo de servidor genérico pelos diretórios especias de configuração em /var,
instalando uma versão especial do kernel (ou configurando um módulo especial do kernel carregável para uso).
Um modelo de servidor de arquivos AFS terá um número muito maior de arquivos replicados copiados localmente a fim de
fazer a máquina tão independente quanto possível dos serviços primários que está provendo.
Upgrade para novas tecnologias
Foi utilizado SunOS 4.1.3 e AIX 3.2.5 no ambiente pre-Aurora, e estes sistemas operacionais foram levados ao limite de
muitas maneiras. Os vendedores tem começado a colocar mais esforço dentro de novos sistemas operacionais, e o mais
moderno hardware é apenas suportado nas mais recentes versões dos sistemas operacionais. Foi escolhido implementar a
porção de configuração do OS do Aurora no Solaris 2.x e AIX 4.x a fim de obter as vantagens disponíveis nestas versões do
OS.
Construindo do nada
Poderia ter sido economizado algum tempo fazendo uso dos modos de compatibilidade binária disponíveis na atualização dos
sistemas operacionais. Foi feita a escolha de não fazer isto. Ao invés, todos os programas (binários ou scripts), foram
cuidadosamente examinados, e sua existência no Aurora tinha que ser justificada. Isto permitiu levar adiante apenas aquelas
aplicações, scripts e metodologias que eram exigidos no novo ambiente, deixando para trás uma porção da infraestrutura
histórica que não era mais necessária ou estava ultrapassada.
Projeto do cliente AFS sem dados
Muitos dos objetivos de projeto acima são encontrados implementando-se um cliente AFS sem dados. Neste projeto, cópias
locais de arquivos replicados (/usr/vice/etc/afsd) estão presentes apenas a fim de criar afsd, a partir deste ponto, tudo é
acessado pelo AFS. Cada cópia mantida localmente na máquina tem que justificar sua exsitência baseada neste critério.
A maioria dos pathnames tradicionais para diretórios inteiros e a maioria dos arquivos de configuração são apenas links
simbólicos para o AFS. Antes de iniciar afsd, /ms é um diretório que contém um link simbólico para /localfs, onde as cópias
reais de arquivos mantidos localmente residem. Uma vez que afsd é inicializado, o espaço de nomes AFS cobre isto, e
arquivos não são mais acessados de /localfs.
Minimizar o conteúdo de /localfs é uma das soluções para minimizar o tempo de instalação e reconfiguração de um host. A
quantidade de dados no modelo Solaris 2.4 atual é menos que 20MB. Na hora do boot, todos os arquivos locais são
checados com as cópias corretas do arquivo no repositório AFS central. Se os arquivos são diferentes, novos arquivos são
copiados para o disco local e a reinicialização ocorre. Isto permite que sempre se guarde arquivos locais atualizados.
Um dos problemas existentes no modelo AFS foi o tempo de inicialização da cache AFS. Foi utilizado um número fixo de
arquivos para afsd inicializar, e a criação de mais de 400 arquivos em uma grande cache leva em torno de 30 minutos para
completar. Este tempo é reduzido para menos de um minuto permitindo-se I/O assíncrona durante a inicialização afsd.
