Apache Cassandra: 6 dicas para preparar um ambiente multi-nuvem
Os incentivos para as organizações adotarem uma estratégia de implementação multi-nuvem – isto é, uma infraestrutura “agnóstica”, com maior resiliência e a flexibilidade de não depender de um único provedor, para citar apenas dois – nunca foram mais convincentes e tem aumentado constantemente. Sim, a façanha tecnológica de implementar e gerenciar deploys que se encaixam em várias nuvens vêm com alguns desafios. Mas à medida que a necessidade de uso de uma arquitetura preparada para o futuro aumenta, o Apache Cassandra tem se mostrado uma solução de banco de dados aberto exclusiva para habilitar essas implementações:
Neste post, separamos 6 dicas para preparar um ambiente multi-nuvem usando o Apache Cassandra:
#1. Disponibilidade de topologia
Os bancos de dados Cassandra permitem a configuração de failure domains, que por sua vez estruturam posicionamentos de réplicas em torno de grupos comuns de máquinas com potencial vulnerabilidade a falhas simultâneas (ou seja, máquinas em um cluster Cassandra que estão no mesmo hypervisor, rack, zona de disponibilidade etc). Desta forma, o Cassandra pode ser informado dos recursos críticos compartilhados para proteger a disponibilidade, mesmo em interrupções em grupo.
#2. Ajustes de consistência
Cassandra permite aos desenvolvedores controlar a consistência de uma query em consonância com os failure domains, dentro de um data center ou rack. Os failure domains em nível de rack são nomeados após os racks físicos reais dentro de um data center, onde as máquinas compartilham energia e infraestrutura de rede. O Cassandra pode garantir que esses racks sejam vinculados por conexões de alta largura de banda/baixa latência e que as réplicas para cada linha em particular sejam armazenadas em locais [de rack] separados. Isso garante que a falha na réplica seja consistente em todo o conjunto de dados e que todos os recursos permanecem disponíveis.
#3. Alerta regional remoto
Os data centers dentro do Cassandra podem ser tratados como locais ou remotos, de forma que o potencial de apresentar menor largura de banda e maior latência é totalmente contabilizado. Os drivers e os nós do Cassandra incluem um alerta do data center local e de quais outros nós estão presentes. Utilizando a consistência ajustável do Cassandra, a força de consistência pode ser isolada em relação ao data center, onde uma determinada consulta é enviada. Os desenvolvedores estão preparados, portanto, para considerar como as queries interagem com a falha do banco de dados e a topologia física, devido ao alerta do Cassandra sobre failure domains remotos e data centers.
#4. Consistência local e global flexíveis
O modelo de domínio de falha do Cassandra é particularmente adequado para a nuvem, oferecendo aos desenvolvedores capacidades tremendas para criar aplicativos que utilizam múltiplos data centers, zonas de disponibilidade e regiões. Com um aplicativo que oferece suporte a várias regiões em um único local, não é difícil estender esse alcance a vários provedores de nuvem – uma região secundária do provedor de nuvem deve apresentar uma latência remota semelhante às regiões remotas do provedor principal.
Como o Cassandra pode isolar a consistência em um data center, adicionar novas regiões ou data centers a um cluster não requer tempo de inatividade e tem impacto insignificante. Ao mesmo tempo, o Cassandra pode garantir aos desenvolvedores que as queries são globalmente confiáveis através de níveis de consistência mais elevados.
#5. Replicação simples e efetiva
O Cassandra facilita a realização de replicação de dados baseada em região ou data center, configurada em nível de keyspace, para que os desenvolvedores possam optar por replicar dados para determinados subconjuntos de região dentro de um cluster Cassandra. Isso, por sua vez, oferece aos desenvolvedores uma maneira simples de atender a requisitos, como necessidades de clientes e negócios ou regulamentos de conformidade governamentais. O Cassandra também facilita a separação de aplicativos ou tabelas que dependem de vários provedores de nuvem daqueles que se relacionam com apenas um provedor.
#6. Flexibilidade no licenciamento de código aberto
Por ser um projeto de software de código aberto, qualquer empresa pode executar o Cassandra com qualquer provedor de nuvem ou data center privado, mantendo um nível de liberdade e flexibilidade que as soluções de banco de dados proprietárias ou os serviços de fornecedores da nuvem simplesmente não podem oferecer. Enquanto os serviços de banco de dados fornecidos pelos provedores de nuvem são projetados para promover vendor lock-in, o Cassandra oferece uma alternativa simples e econômica para evitar o lock-in com um único fornecedor de nuvem.
Chegar a uma verdadeira implementação multi-nuvem ou de deploy híbrido é algo desafiador, dadas as diferenças nos ambientes de fornecedores de nuvem e a necessidade de processos separados e caminhos de código necessários para gerenciar o gerenciamento de configuração, CI/CD, alertas, planejamento de recursos e roteamento/DNS. No entanto, a força do Cassandra como banco de dados de código aberto adequado à implementação multi-nuvem significa que a camada de dados é livre desses problemas.
Combinar o Cassandra com outras soluções padronizadas populares pode capacitar uma empresa com uma pilha de aplicativos que é extensível a vários provedores de nuvem. Algo especialmente oportuno, já que mais e mais empresas se voltam para estratégias de longo prazo envolvendo várias nuvens.
Fonte: opensource.com
Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.