Armazenamento definido pelo software
Como você já viu, diferentes tipos de sistemas de armazenamento podem ser implantados com base nas necessidades do aplicativo. A forma mais básica de armazenamento é o armazenamento anexado diretamente, no qual os dispositivos de armazenamento, como discos magnéticos ou SSDs, são diretamente anexados a um servidor internamente (por meio de uma conexão de barramento interna, geralmente SATA ou SAS). Por outro lado, sistemas de armazenamento maciços e de nível empresarial podem ser usados na forma de uma SAN (rede de área de armazenamento), que usa uma rede (empregando diferentes tecnologias) para conectar servidores a um pool de discos.
Lembre-se de que, em nuvens, os recursos de computação física são compartilhados entre vários locatários por meio de servidores virtualizados. Essa abordagem também pode se aplicar aos recursos de armazenamento. Os recursos de armazenamento podem ser compartilhados entre vários locatários, reduzindo o custo e aprimorando a utilização geral desses recursos. No entanto, uma forma de isolamento deve ser fornecida juntamente com a tolerância a falhas e outras tecnologias para atender aos SLOs de um aplicativo específico. Isso permite que os clientes tenham um comportamento previsível para seus aplicativos, ao mesmo tempo que compartilham recursos de armazenamento com outros locatários. Fornecer SLOs de ponta a ponta resultaria em requisitos de largura de banda, de IOPS (operações de entrada/saída por segundo), de prioridade ou de controle sobre todo o caminho de E/S, conforme mostrado na figura a seguir.
Figura 7: Um exemplo de caminho de E/S
O SDS (armazenamento definido pelo software) permite aos clientes especificar os requisitos refinados de capacidade, latência e/ou largura de banda, na forma de SLOs, que são mapeados a fim de abstrair os serviços de armazenamento para o cliente. O provedor de nuvem pode montar e fornecer um serviço de armazenamento escalonável usando várias tecnologias de armazenamento no back-end. Os SLOs de cliente podem ser atendidos por meio do gerenciamento da pilha de armazenamento do lado do provedor.
Para entender melhor como isso pode ser realizado, vejamos uma das tecnologias emergentes que permitem SDS, IOFlow.1
Exemplo de SDS: IOFlow
Nos datacenters, a operação de um aplicativo solicitando operações de arquivo e o sistema de armazenamento cumprindo as operações é complexa e envolve várias fases, como o SO host, o hipervisor, a malha de rede, o servidor de armazenamento e por fim, uma operação de disco. A solicitação também aparece de maneira diferente em cada camada. Por exemplo, uma solicitação de E/S de arquivo como leitura, gravação ou criação em uma VM resulta em uma solicitação de E/S de blocos no hipervisor. Isso, por sua vez, resulta em pacotes Ethernet na rede e por fim, em outra solicitação de E/S de arquivo e solicitação de dispositivo de blocos no servidor de armazenamento.
O número de camadas do sistema indica que é difícil impor uma política de fluxo de ponta a ponta (tais políticas normalmente são derivadas de um SLO). Isso requer camadas ao longo do caminho de E/S para tratar as solicitações de maneira diferente com base em seu conteúdo e/ou nos SLOs do cliente. Além disso, pode ser necessário impor políticas em uma, em várias ou em todas as camadas ao longo do caminho. Por exemplo, a priorização de E/Ss de uma VM específica para armazenamento requer a configuração da priorização em todas as camadas ao longo do caminho.
O IOFlow é uma arquitetura de armazenamento definida pelo software e projetada pela Microsoft para manter os SLOs de ponta a ponta e de largura de banda e também para aprimorar o desempenho. Os clientes são VMs em execução em servidores de computação por meio de um hipervisor. Essas VMs precisam de acesso ao servidor de armazenamento, que é regulamentado pelo IOFlow. O fluxo de dados é alcançado pelo uso de filas em cada fase do caminho de E/S. Essas filas são regulamentadas por um controlador centralizado. O controlador centralizado na arquitetura do IOFlow atribui métricas de taxa de dados e a rota em cada fase da arquitetura geral.
Um exemplo de caminho de E/S típico da VM para o servidor de armazenamento é apresentado na Figura 8. Um servidor de computação, que consiste em uma série de VMs em execução simultaneamente, interage com um servidor de armazenamento. Assim, a interação do aplicativo com um sistema de arquivos em uma VM se transforma em solicitações de dispositivo de blocos no VHD (disco rígido virtual). Neste exemplo específico, o disco rígido virtual é, na verdade, um servidor de armazenamento remoto que serve arquivos usando o protocolo SMB da Microsoft. Portanto, as solicitações de E/S ainda são convertidas em um pacote de rede no driver de rede do hipervisor e enviadas para o servidor de armazenamento remoto por meio da rede. No servidor de armazenamento, o pacote de rede é desencapsulado em cada camada, transformando-se em uma solicitação SMB, que, por sua vez, é convertida em uma solicitação do sistema de arquivos no servidor de armazenamento. Em cada camada desse caminho de E/S, o IOFlow adiciona uma abstração de fila, que então é exposta ao controlador IOFlow. O controlador pode converter essas políticas em regras de enfileiramento de nível inferior em cada fase.
Figure 8: IOFlow example (Fonte)
O controlador do IOFlow regula o tráfego de E/S da seguinte maneira:
- O controlador do IOFlow obtém um grafo de toda a rede sob seu domínio, inclusive onde as fases compatíveis estão localizadas.
- As políticas (explicadas abaixo) compatíveis com o controlador são escolhidas pelo cliente.
- Com base na política do cliente, as filas são formadas e configuradas em fases intermediárias.
- Quando o tráfego de E/S passa por essas fases intermediárias, o cabeçalho de E/S é reconhecido e a política correspondente é implementada.
O IOFlow implementa identificadores de fluxo, que são basicamente cabeçalhos de E/S anexados a solicitações de E/S individuais. Esses cabeçalhos de baixo nível são anexados à E/S como os cabeçalhos de alto nível e não podem ser reconhecidos pelas fases intermediárias. Quando as fases intermediárias identificam um cabeçalho, elas o usam como informações de roteamento para rotear a E/S para o próximo salto.
Como exemplo da forma como o SDS pode usar políticas para regulamentar o tráfego de E/S, o IOFlow atualmente apresenta as cinco políticas de fluxo seguintes:
| Flow | Descrição |
|---|---|
| P1 | Uma VM (VM1) tem garantida uma largura de banda fixa, B. |
| P2 | Quando houver largura de banda extra disponível, a VM1 terá permissão para exceder B. |
| P3 | Política de sanitização; o tráfego de E/S é roteado por meio de uma camada de sanitização (como detecção de malware). |
| P4 | Prioridade alta; o tráfego de dados da VM2 deve receber prioridade alta de ponta a ponta. |
| P5 | Várias VMs que pertencem ao mesmo cliente e que acessam um pool comum de recursos podem ter a largura de banda garantida B. |
Em P1, é prometido a cada VM uma largura de banda mínima para acessar um ou mais servidores de armazenamento. No entanto, em P2, se houver largura de banda extra disponível como resultado de uma das VMs pares ficarem ociosas, a largura de banda disponível para VM1 poderá ser alterada dinamicamente. P3 requer que o tráfego seja roteado para uma camada de sanitização. Por exemplo, uma nova VM não confiável pode ter seu tráfego roteado para um sistema de detecção de malware. P4 pode garantir operações de baixa latência atribuindo prioridade alta ao tráfego de armazenamento na VM2. P5 permite a garantia de largura de banda para um conjunto de VMs que precisam acessar servidores de armazenamento específicos. As políticas P1 a P4 são especificadas para fluxos ponto a ponto, ao passo que as políticas P5 são especificadas para vários fluxos.
O SDS é uma abordagem de rápida evolução para fornecer armazenamento como serviço que atenda aos SLOs de um cliente por meio de sistemas de armazenamento compartilhados. Como mencionado acima, o compartilhamento sem garantias de SLO de ponta a ponta não será prontamente adotado. O IOFlow é um exemplo inicial de tecnologia SDS. Esperamos que a inovação no espaço do SDS continue em um ritmo acelerado, trazendo consigo novas soluções que tentarão atender aos requisitos dos novos aplicativos de nuvem.
Referências
- Thereska et al. (2013). IOFlow: Uma Arquitetura de Armazenamento Definida por Software SOSP'13: O 24º Simpósio ACM sobre Princípios de Sistemas Operacionais