A História da Divisão de Arrays

Grande parte do conhecimento decorado da área de TI, especialmente da área das PME, surgiu no final dos anos 1990 com base numa variedade de fatores. Os maiores fatores foram que, de repente, empresas cada vez menores se apressavam a informatizar-se, a Microsoft tinha tornado o Windows NT 4 tão estável que havia uma base padrão em torno da qual toda a TI das PME se podia centrar, a era da Internet tinha finalmente vingado e a Microsoft introduziu os seus programas de certificação e formação que remodelaram a disseminação do conhecimento na indústria. Em conjunto, isto criou tanto uma necessidade de nova formação e de boas práticas como provocou uma explosão massiva de novo pensamento, escrita, documentação, formação, boas práticas, regras práticas, etc.

Durante alguns anos, praticamente toda a área foi formada com base no mesmo pequeno conjunto de conhecimentos, e muitas regras práticas tornaram-se padrões de facto, sendo que grande parte do conhecimento da época era aprendido de cor e transmitido de mentor para estagiário num ciclo que levou grande parte do conhecimento técnico de 1998 aos processos inquestionáveis e imutáveis de 2012. Na altura, isto era eficaz porque as práticas eram relevantes, mas isso foi há quinze anos; a tecnologia, a economia, os casos de uso e o conhecimento mudaram significativamente desde então.

Um dos melhores exemplos disto foi a famosa recomendação do Microsoft SQL Server de RAID 1 para o sistema operativo, RAID 5 para os ficheiros da base de dados e outro RAID 1 para os registos. Esta configuração perdurou durante praticamente toda a vida do produto e foi tão bem divulgada que se difundiu por quase todos os aspetos do projeto de servidores no espaço das PME. O uso de RAID 1 para o sistema operativo e RAID 5 para os dados é tão generalizado que é frequentemente assumido sem qualquer reflexão sobre por que motivo isto foi recomendado na altura.

Vamos investigar a história e perceber por que motivo o R1/5/1 era bom em 1998 e por que motivo não deveria existir hoje. Tenha alguma perspetiva em mente: o fosso entre o momento em que estas recomendações surgiram pela primeira vez (logo em 1995) e os dias de hoje é imenso. Recue mentalmente até 1995 e pense no fosso equivalente da altura. Teria sido como usar, na era inicial da Internet, recomendações baseadas nas necessidades de informática doméstica da primeira geração de proprietários de Apple ][! A era dos computadores domésticos de 8 bits estava apenas a dar os primeiros passos em 1978. A Commodore ainda estava a dois anos de lançar o seu primeiro computador doméstico (o VIC-20) e atravessaria toda a era da Commodore e da Commodore Amiga, e iria à falência e desapareceria, tudo antes de 1995. O Apple ][+ ainda estava a um ano de distância. As pessoas estavam mesmo prestes a começar a usar gravadores de cassetes analógicas como armazenamento. COBOL e Fortran eram as únicas linguagens empresariais sérias em uso. Em suma, o fosso é incrível. As coisas mudam.

Primeiro, precisamos de olhar para os fatores que existiam no final dos anos 1990 e que criaram a necessidade da nossa configuração histórica.

1. Os discos eram pequenos, muito pequenos. Um grande array de base de dados poderia ter quatro discos SCSI de 2,1 GB num array R5, para apenas cerca de 6 GB de espaço de armazenamento utilizável num único array. O domínio de falha para a falha do RAID de paridade era minúsculo (comparado com coisas como as taxas de falha por URE.)
2. As tecnologias de ligação dos discos eram paralelas e lentas. Os discos rígidos da época eram apenas ligeiramente mais lentos do que os discos de hoje, mas as tecnologias de ligação representavam um estrangulamento considerável. Era comum dividir o tráfego para permitir reduzir os estrangulamentos do barramento.
3. A tecnologia de discos SCSI era a única utilizada em servidores. O uso de um PATA (na altura chamado IDE) num servidor era impensável.
4. Os discos eram caros por gigabyte, pelo que a poupança de custos era a questão central, mantendo a capacidade, para praticamente todas as empresas.
5. Os sistemas de ficheiros eram frágeis e falhavam mais frequentemente do que os discos.
6. O RAID por hardware era obrigatório e apenas os níveis básicos de RAID, 1 e 5, estavam comummente disponíveis. O RAID 6 e o RAID 10 estavam a anos de distância de serem acessíveis à maioria das empresas. O RAID 0 é desconsiderado por não ter redundância.
7. Os sistemas de armazenamento raramente, ou nunca, eram partilhados entre servidores, pelo que o acesso estava quase sempre dedicado a uma única fila de pedidos.
8. As caches de armazenamento eram minúsculas ou inexistentes, fazendo com que as limitações de acesso aos discos passassem diretamente para o sistema operativo. Isto significava ter arrays diferentes com características diferentes para lidar com diferentes misturas de acesso de leitura/escrita ou aleatório/sequencial.
9. A falha de discos era comum e a principal preocupação no projeto de sistemas de armazenamento.
10. Muitas vezes o tamanho do array de discos era limitado por restrições físicas, pelo que frequentemente as decisões de divisão de arrays eram tomadas por necessidade, e não por escolha.
11. Uma combinação dos fatores acima significava que o RAID 1 era melhor para algumas partes do sistema em que um tamanho pequeno era aceitável e o acesso era altamente sequencial ou intensivo em escrita, e o RAID 5 era melhor para outras em que a capacidade superava a fiabilidade e em que o acesso era altamente aleatório e intensivo em leitura.

Nas quase duas décadas desde que as recomendações originais foram divulgadas, todos estes fatores mudaram. Em alguns casos, as mudanças são em cascata, em que a passagem do RAID 5 de uso geral para o RAID 10 de uso geral fez então com que aqueles que teriam sido os dois tipos de array comuns, o RAID 1 e o RAID 10, passassem a partilhar as características de acesso, pelo que a necessidade ou o desejo de usar um ou outro consoante o tipo de carga deixou de existir.

1. Os discos são agora enormes. Em vez de termos dificuldade em fazer caber aquilo de que precisamos neles, geralmente temos capacidade em excesso. Discos individuais com mais de um terabyte são comuns, mesmo em servidores. Os domínios de falha para a paridade são enormes (comparados com coisas como as taxas de falha por URE.)
2. As ligações dos discos são em série e rápidas. As ligações dos discos já não constituem um estrangulamento.
3. O SATA é agora comum em servidores, distorcendo os potenciais riscos de URE de uma forma que não existia anteriormente.
4. A capacidade é agora barata, mas o desempenho e a fiabilidade são agora as principais preocupações para o dinheiro gasto.
5. Os sistemas de ficheiros são hoje altamente robustos e as falhas de sistema de ficheiros são “ruído de fundo” no panorama mais amplo da fiabilidade dos arrays.
6. O RAID por hardware e o RAID por software são ambos opções hoje em dia, e os níveis de RAID disponíveis incluem muitas opções mas, mais importante ainda, o RAID 10 está disponível de forma ubíqua.
7. Os sistemas de armazenamento são comummente partilhados, tornando o acesso sequencial ainda menos comum.
8. As caches de armazenamento são comuns e, muitas vezes, muito grandes. Caches de 512 MB e 1 GB são consideradas normais hoje em dia, fazendo com que muitos arrays de 1995 caibam inteiramente na memória do controlador RAID atual. Com as caches a crescer rapidamente em comparação com a capacidade de armazenamento e com a recente adição, nos últimos dois anos, de discos de estado sólido como cache L2 no armazenamento, não é descabido que mesmo uma pequena empresa tenha bases de dados e outras aplicações sensíveis ao desempenho a correr inteiramente a partir da cache.
9. A falha de discos é pouco comum e de preocupação trivial para o projeto de sistemas de armazenamento (em comparação com outros tipos de falha.)
10. O tamanho do array de discos raramente é limitado por restrições físicas.
11. O uso do RAID 1 e do RAID 10 como os principais tipos de array atuais significa que não há benefício em usar diferentes níveis de array para afinação de desempenho.

Estes fatores realçam por que motivo o sistema de arrays divididos de 1995 fazia todo o sentido na altura e por que motivo não faz sentido hoje. O OBR10, o padrão atual, não estava disponível na altura e era proibitivamente caro. O RAID 5 era relativamente seguro em 1995, mas não hoje. Quase todos os fatores envolvidos no processo de decisão mudaram dramaticamente nos últimos dezassete anos e vão continuar a mudar à medida que o SSD se torna mais comum, juntamente com o auto-tiering, caches ainda maiores e sistemas de armazenamento puramente em SSD.

A mudança no projeto de armazenamento ao longo das últimas duas décadas também realça os perigos que a TI enfrenta na medida em que uma grande parte da área aprende, como é comum em engenharia, “regras práticas” ou “boas práticas” básicas sem necessariamente compreender os princípios subjacentes que orientam essas decisões, tornando difícil saber quando não aplicar essas boas práticas ou, mais importante ainda, quando reconhecer que a regra já não se aplica. Ao contrário da engenharia mecânica ou civil tradicional, onde novos avanços e mudanças significativas de fatores podem ocorrer uma vez ou possivelmente nunca ao longo de uma carreira, a TI ainda muda suficientemente depressa para que sejam necessárias “reformulações” completas das regras práticas básicas várias vezes ao longo de uma carreira. Talvez não anualmente, mas uma vez por década ou mais é quase sempre necessário.

A atual transição do processamento único para arquiteturas multifio é outra mudança semelhante e significativa que exige que a área de TI mude completamente a forma como o projeto de sistemas é tratado.