Guia de upgrade do Data Center
Nenhuma empresa é igual, assim como jornadas de migração. Siga o guia de upgrade passo a passo para garantir uma transição suave do Atlassian Server para o Data Center.
Avaliar
Cada empresa tem necessidades e requisitos próprios. Portanto, é importante entender as opções para planejar upgrades.
Entenda seus requisitos de arquitetura e infraestrutura
Decidiu pelo Data Center? Você vai precisar conhecer a arquitetura e as configurações de implementação do Data Center com suporte.
O Data Center pode ser implementado de duas maneiras diferentes: com ou sem cluster. Ambas permitem que você aproveite funções e capacidades corporativas, mas cada opção requer considerações diferentes. Esta é uma tabela que descreve as diferenças entre arquiteturas com e sem cluster:
Sem cluster recomendado
Requisitos de infraestrutura
Uma arquitetura sem cluster permite que você faça o upgrade para o Data Center na infraestrutura existente, para que não precise fazer nenhuma alteração na infraestrutura.
Casos de uso recomendados
A gente recomenda que todos os clientes façam o upgrade para o Data Center usando o caminho de upgrade sem cluster. Os clientes podem implementar uma arquitetura em cluster uma vez no Data Center, se necessário.
Benefícios
Desbloqueie as funções corporativos que não dependem de clustering:
Em geral, os upgrades sem cluster são o ponto em que muitos clientes iniciam a jornada no Data Center. É recomendável aproveitar esse upgrade de 2 minutos para garantir uma transição tranquila.
Com cluster
A gente recomenda que todos os clientes façam o upgrade para o Data Center primeiro usando o caminho de upgrade sem cluster. Depois do upgrade do Data Center, os clientes podem implementar uma arquitetura em cluster, se necessário.
Requisitos de infraestrutura
Você vai precisar dos seguintes componentes para fazer upgrade para o Data Center em um cluster:
- Balanceador de carga
- Pontos centrais de aplicativo
- Sistema de arquivos acessível por todos os pontos centrais do aplicativo
- Ponto central do ElasticSearch (Bitbucket)
Casos de uso recomendados
- Você precisa de alta disponibilidade
- Você quer fazer o upgrade sem tempo de inatividade
- Você espera aumentar para tamanho XL no curto prazo
Benefícios
Descubra as funções corporativas que o clustering oferece:
- Funções e capacidades corporativas
- Alta disponibilidade e failover — se um ponto central no cluster do aplicativo ficar inativo, os outros assumem a carga, garantindo que os usuários tenham acesso ininterrupto ao produto.
- Escalabilidade instantânea — adicione novos pontos centrais ao cluster sem tempo de inatividade ou taxas de licenciamento adicionais. Os índices e plugins são automaticamente sincronizados.
- Recuperação de desastres — implemente um sistema de recuperação de desastres fora do local para a continuidade dos negócios, mesmo em caso de uma interrupção completa do sistema. Os índices de produtos compartilhados deixam tudo funcionando de novo com rapidez.
Planeje e se prepare
Agora que você escolheu o caminho do Data Center, está tudo pronto para começar a criar um plano minucioso de upgrade.
Monte um cronograma Obrigatório
Aqui estão os cronogramas básicos que você pode usar para avaliar quanto tempo o upgrade deve levar.
| | Sem cluster | Com cluster |
|---|---|---|
| Planejamento | Sem cluster 0 a 2 semanas | Com cluster 1 mês + |
| Simulação | Sem cluster 0 a 1 semana | Com cluster 3 a 6 meses |
| Lançamento | Sem cluster 0 a 1 semana | Com cluster ~6 a 9 meses |
Os cronogramas incluídos são baseados em diversos clientes que fizeram o upgrade para o Data Center, mas é importante observar que o cronograma real vai variar em razão de fatores específicos do ambiente, como tamanho, complexidade e preparação, entre outros.
Defina seu ambiente de Data Center Obrigatório
Camada de aplicativo
Instâncias e sites
- Você quer federar ou consolidar suas instâncias?
- Como é o seu crescimento futuro?
- Você precisa ter algum isolamento de dados?
- Quantos ambientes sua equipe tem, como ambientes de staging ou produção?
Perfis da instância
- Quantas pessoas vão acessar sua instância?
- Onde suas equipes vão estar localizadas?
- Quantos dados estão atualmente em sua instância e quantos dados você planeja adicionar à instância?
Aplicativos, integrações e personalização
Você precisa de todos eles, ou esta é uma oportunidade de simplificar?
Camada de infraestrutura
Tamanho da instância
- Quais são suas projeções de crescimento futuro?
- Há momentos em que você tem níveis mais baixos de tráfego de usuários?
Para obter mais informações, consulte a visão geral de dimensionamento de pontos centrais.
Estrutura da conta
- Em quais contas seu ambiente deve ser implementado?
- Você quer contas diferentes associadas a cada um dos seus ambientes?
- Você quer que seus produtos de Data Center usem a mesma conta que suas outras ferramentas de CI/CD ou de colaboração?
Modelo de governança
- Qual é a aparência do seu modelo de governança?
- Quais são seus padrões mínimos de sistema?
- Você está usando o registro em log centralizado?
- Quais são as suas necessidades de gerenciamento de usuários?
Considere usar a zona de aterrissagem da AWS e o Gerenciador de Sistema da AWS como parte do seu modelo de governança.
VPC
-
Você quer usar uma nova nuvem privada virtual (VPC)?
Se você quer implementar em uma nova VPC ou usar uma existente, você pode aproveitar o template Atlassian Standard Infrastructure (ASI).
- Existem princípios de rede que você quer alterar, como limitar o acesso público à Internet e o endereçamento de IP interno para roteamento de rede de escritório e VPN?
- Você deve usar certificados TLS?
Geografia
-
Se estiver usando uma VPC existente, você criou um plano para acesso à rede de escritório e VPN?
A gente recomenda que você permita o acesso de todos os escritórios e VPNs, pois o uso do produto provavelmente vai aumentar com o tempo.
Direct Connect
- Você quer usar o Direct Connect para ajudar com desempenho e segurança?
- Quantos dados você precisa mover da instância do servidor para o Data Center?
A família AWS Snow pode ser um recurso que você pode considerar se estiver movendo grandes quantidades de dados.
Continuidade de negócios e recuperação de desastres
Backup
Qual é a aparência da sua estratégia de backup?
A gente recomenda que você use uma combinação da estratégia de backup existente e dos recursos de backup incorporados à AWS. Para obter mais informações, consulte:
A AWS oferece serviços de infraestrutura menos propensos a interrupções singulares.
Failover regional
Você precisa implementar sites frios, mornos ou quentes em diferentes regiões?
Normalmente, suas necessidades de recuperação de desastres são atendidas com a execução de seus serviços em várias zonas de disponibilidade, mas você também pode querer mitigar as interrupções regionais. Ao decidir se quer implementar esses sites em diferentes regiões, considere o seguinte:
- Custo da infraestrutura e da transferência de dados
- Velocidade de recuperação em relação à AWS
- Tempo gasto na manutenção e no teste do site de recuperação
- Custo de execução do site
Fazer upgrade para o Data Center (sem cluster) recomendado
A gente recomenda que todos os clientes façam o upgrade para o Data Center usando uma arquitetura sem cluster. Os upgrades sem cluster são uma opção de upgrade mais rápida e simplificada, oferecendo acesso mais rápido às funções empresariais, de segurança e suporte do Data Center.
Fazer upgrade para o Data Center (com cluster) não recomendado
Devido à complexidade, a gente não recomenda fazer upgrades iniciais para o Data Center em arquitetura em cluster. A gente recomenda que todos os clientes primeiro façam o upgrade para o Data Center usando o caminho de upgrade sem cluster. Depois disso, os clientes que precisam de uma arquitetura em cluster podem começar a implementação.
Depois de fazer o upgrade para o Data Center em arquitetura sem cluster, você vai poder implementar uma arquitetura em cluster se precisar de alta disponibilidade.
Adquira a infraestrutura necessária para seu cluster
Para implementar o Data Center em um cluster, você vai precisar dos seguintes componentes:
- Banco de dados
- Balanceador de carga
- Pontos centrais de aplicativo
- Sistema de arquivos compartilhados
- Ponto central do ElasticSearch (Bitbucket)
Balanceador de carga
O balanceador de carga é a primeira coisa que as solicitações dos usuários atingem se você implementou em um cluster. As solicitações chegam ao balanceador de carga, e o balanceador de carga distribui cada solicitação aos pontos centrais do aplicativo. Você pode usar um balanceador de carga baseado em hardware ou software. Para soluções de software e hardware, o balanceador de carga deve ser vinculado ao cluster do aplicativo usando uma conexão LAN de alta velocidade para garantir alta largura de banda e baixa latência. Todos os balanceadores de carga de software devem ser executados em máquinas dedicadas.
Os produtos do Data Center presumem que a solicitação de cada usuário vai para o mesmo ponto central durante uma sessão. Se as solicitações forem para pontos centrais diferentes, os usuários podem ser desconectados inesperadamente e podem até perder informações armazenadas na sessão. Portanto, é necessário associar uma sessão ao mesmo ponto central, habilitando “sessões fixas” (ou afinidade de sessão) baseadas em cookies no balanceador de carga. Ao usar sessões fixas baseadas em cookies, você pode usar o cookie emitido pelo produto ou um cookie gerado pelo balanceador de carga.
Adicione uma camada extra de proteção e evite que o balanceador de carga se torne um único ponto de falha adicionando redundância à solução de balanceamento de carga. Configure dois balanceadores de carga em uma configuração ativo-passivo, usando um endereço IP virtual em ambos os balanceadores de carga. Se o balanceador de carga ativo falhar, ele vai fazer failover para o balanceador de carga passivo.
Para obter mais informações consulte as opções de configuração do balanceador de carga.
Pontos centrais de aplicativo
Os pontos centrais dos aplicativos são onde o produto real reside. Cada ponto central no cluster do Data Center deve ser executado na mesma versão do produto e estar localizado junto para manter um mínimo de latência. No entanto, você pode habilitar uma rede de distribuição de conteúdo (CDN) para dar suporte ao desempenho das equipes distribuídas em lugares diferentes. Esses pontos centrais devem ser configurados em um cluster, agindo como um só, para entregar o produto aos usuários. O número de pontos centrais no cluster depende das necessidades e da configuração do produto. Em geral, a gente descobre que entre 2 e 4 pontos centrais são suficientes para a maioria dos clusters, mas use os guias de dimensionamento de pontos centrais para tomar a decisão certa.
O Bitbucket requer um ponto central de aplicativo adicional dedicado apenas ao ElasticSearch, que permite a pesquisa de código.
Sistema de arquivos compartilhados
O sistema de arquivos compartilhados é onde os dados que devem ser acessados de qualquer ponto central do aplicativo são armazenados, como arquivos anexados e repositórios do Git.
Em um ambiente do Data Center, você precisa configurar o sistema de arquivos compartilhado como seu próprio ponto central. Você pode usar qualquer programa NAS ou SAN baseado em NFS para seu sistema de arquivos compartilhado, mas a gente recomenda o NFS3 para manter o desempenho. Apenas fique longe de protocolos distribuídos como DFS, pois eles não são compatíveis.
Crie um ambiente de staging
Para fazer o upgrade para múltiplos pontos centrais, é recomendável criar um ambiente de staging para testar o Data Center antes de entrar em operação na produção.
O ambiente de staging deve replicar com fidelidade o seu ambiente de produção, incluindo proxies reversos, configuração SSL ou balanceador de carga. Você pode optar por usar um servidor físico diferente ou uma solução virtualizada. O principal é se certificar de que seja uma réplica adequada do ambiente de produção.
Para obter instruções detalhadas, consulte:
Fale com um parceiro
Tem alguma dúvida sobre as opções de migração ou de caminho? Receba orientação especializada da equipe de especialistas em migração.