O Nextcloud é um aplicativo de compartilhamento e sincronização de arquivos de código aberto que oferece armazenamento de arquivos em nuvem gratuito, seguro e de fácil acesso, além de várias ferramentas que estendem seu conjunto de recursos. É muito semelhante ao popular Dropbox, iCloud e Google Drive, mas ao contrário do Dropbox, o Nextcloud não oferece hospedagem de armazenamento de arquivos fora do local.
Nesta postagem do blog, vamos implantar uma configuração de alta disponibilidade para nossa infraestrutura "Dropbox" privada usando Nextcloud, GlusterFS, Percona XtraDB Cluster (MySQL Galera Cluster), ProxySQL com ClusterControl como ferramenta de automação para gerenciar e monitorar as camadas do banco de dados e do balanceador de carga.
Observação:você também pode usar o MariaDB Cluster, que usa a mesma biblioteca de replicação subjacente do Percona XtraDB Cluster. Do ponto de vista do balanceador de carga, o ProxySQL se comporta de maneira semelhante ao MaxScale, pois pode entender o tráfego SQL e tem controle refinado sobre como o tráfego é roteado.
Arquitetura de banco de dados para Nexcloud
Nesta postagem do blog, usamos um total de 6 nós.
- 2 x servidores proxy
- 3 x banco de dados + servidores de aplicativos
- 1 x servidor controlador (ClusterControl)
O diagrama a seguir ilustra nossa configuração final:
Para Percona XtraDB Cluster, é necessário um mínimo de 3 nós para um sólido replicação multimestre. Os aplicativos Nextcloud são colocados dentro dos servidores de banco de dados, portanto, o GlusterFS também deve ser configurado nesses hosts.
A camada do balanceador de carga consiste em 2 nós para fins de redundância. Usaremos o ClusterControl para implantar a camada de banco de dados e as camadas do balanceador de carga. Todos os servidores estão rodando no CentOS 7 com a seguinte definição de /etc/hosts em cada nó:
192.168.0.21 nextcloud1 db1
192.168.0.22 nextcloud2 db2
192.168.0.23 nextcloud3 db3
192.168.0.10 vip db
192.168.0.11 proxy1 lb1 proxysql1
192.168.0.12 proxy2 lb2 proxysql2
Observe que GlusterFS e MySQL são processos altamente intensivos. Se você estiver seguindo esta configuração (GlusterFS e MySQL residem em um único servidor), certifique-se de ter especificações de hardware decentes para os servidores.
Implantação do banco de dados Nextcloud
Começaremos com a implantação do banco de dados para nosso cluster Percona XtraDB de três nós usando o ClusterControl. Instale o ClusterControl e configure o SSH sem senha para todos os nós que serão gerenciados pelo ClusterControl (3 PXC + 2 proxies). No nó ClusterControl, faça:
$ whoami
root
$ ssh-copy-id 192.168.0.11
$ ssh-copy-id 192.168.0.12
$ ssh-copy-id 192.168.0.21
$ ssh-copy-id 192.168.0.22
$ ssh-copy-id 192.168.0.23
**Digite a senha de root para o respectivo host quando solicitado.
Abra um navegador da Web e vá para https://{ClusterControl-IP-address}/clustercontrol e crie um superusuário. Em seguida, vá para Implantar -> MySQL Galera. Siga o assistente de implantação adequadamente. No segundo estágio 'Definir Servidores MySQL', escolha Percona XtraDB 5.7 e especifique o endereço IP para cada nó do banco de dados. Certifique-se de obter um visto verde após inserir os detalhes do nó do banco de dados, conforme mostrado abaixo:
Clique em "Implantar" para iniciar a implantação. O cluster de banco de dados estará pronto em 15 a 20 minutos. Você pode acompanhar o progresso da implantação em Activity -> Jobs -> Create Cluster -> Full Job Details. O cluster será listado no painel do Cluster de Banco de Dados após a implantação.
Agora podemos prosseguir para a implantação do balanceador de carga do banco de dados.
Implementação do balanceador de carga do banco de dados Nextcloud
Recomenda-se que o Nextcloud seja executado em uma configuração de gravador único, onde as gravações serão processadas por um mestre por vez e as leituras podem ser distribuídas para outros nós. Podemos usar o ProxySQL 2.0 para obter essa configuração, pois ele pode rotear as consultas de gravação para um único mestre.
Para implantar um ProxySQL, clique em Cluster Actions> Add Load Balancer> ProxySQL> Deploy ProxySQL. Insira as informações necessárias conforme destacado pelas setas vermelhas:
Preencha todos os detalhes necessários conforme destacado pelas setas acima. O endereço do servidor é o servidor lb1, 192.168.0.11. Mais abaixo, especificamos o administrador do ProxySQL e a senha dos usuários de monitoramento. Em seguida, inclua todos os servidores MySQL no conjunto de balanceamento de carga e escolha "Não" na seção Transações Implícitas. Clique em "Implantar ProxySQL" para iniciar a implantação.
Repita as mesmas etapas acima para o balanceador de carga secundário, lb2 (mas altere o "Endereço do servidor" para o endereço IP de lb2). Caso contrário, não teríamos redundância nesta camada.
Nossos nós ProxySQL agora estão instalados e configurados com dois grupos de hosts para o Galera Cluster. Um para o grupo de mestre único (hostgroup 10), onde todas as conexões serão encaminhadas para um nó Galera (isso é útil para evitar deadlocks de vários mestres) e o grupo de vários mestres (hostgroup 20) para todas as cargas de trabalho somente leitura que será balanceado para todos os servidores MySQL de backend.
Em seguida, precisamos implantar um endereço IP virtual para fornecer um único endpoint para nossos nós ProxySQL para que seu aplicativo não precise definir dois hosts ProxySQL diferentes. Isso também fornecerá recursos de failover automático porque o endereço IP virtual será assumido pelo nó ProxySQL de backup caso algo dê errado no nó ProxySQL primário.
Vá para ClusterControl -> Gerenciar -> Load Balancers -> Keepalived -> Deploy Keepalived. Escolha "ProxySQL" como o tipo de balanceador de carga e escolha dois servidores ProxySQL distintos na lista suspensa. Em seguida, especifique o endereço IP virtual, bem como a interface de rede que ele escutará, conforme mostrado no exemplo a seguir:
Depois que a implantação for concluída, você verá os seguintes detalhes na barra de resumo do cluster:
Finalmente, crie um novo banco de dados para nosso aplicativo indo para ClusterControl -> Manage -> Schemas and Users -> Create Database e especifique "nextcloud". O ClusterControl criará esse banco de dados em cada nó Galera. Nosso nível de balanceador de carga agora está completo.
Implantação do GlusterFS para Nextcloud
As etapas a seguir devem ser executadas em nextcloud1, nextcloud2, nextcloud3, a menos que especificado de outra forma.
Primeiro passo
É recomendado ter um this separado para armazenamento GlusterFS, então vamos adicionar um disco adicional em /dev/sdb e criar uma nova partição:
$ fdisk /dev/sdb
Siga o assistente de criação de partição fdisk pressionando a seguinte tecla:
n > p > Enter > Enter > Enter > w
Passo Dois
Verifique se /dev/sdb1 foi criado:
$ fdisk -l /dev/sdb1
Disk /dev/sdb1: 8588 MB, 8588886016 bytes, 16775168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Passo Três
Formate a partição com XFS:
$ mkfs.xfs /dev/sdb1
Passo Quatro
Monte a partição como /storage/brick:
$ mkdir /glusterfs
$ mount /dev/sdb1 /glusterfs
Verifique se todos os nós têm o seguinte layout:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 40G 0 disk
└─sda1 8:1 0 40G 0 part /
sdb 8:16 0 8G 0 disk
└─sdb1 8:17 0 8G 0 part /glusterfs
Passo Cinco
Crie um subdiretório chamado brick em /glusterfs:
$ mkdir /glusterfs/brick
Passo Seis
Para redundância de aplicativos, podemos usar GlusterFS para replicação de arquivos entre os hosts. Primeiramente, instale o repositório GlusterFS para CentOS:
$ yum install centos-release-gluster -y
$ yum install epel-release -y
Etapa Sete
Instale o servidor GlusterFS
$ yum install glusterfs-server -y
Etapa Oito
Ative e inicie o daemon do Gluster:
$ systemctl enable glusterd
$ systemctl start glusterd
Passo Nove
No nextcloud1, teste os outros nós:
(nextcloud1)$ gluster peer probe 192.168.0.22
(nextcloud1)$ gluster peer probe 192.168.0.23
Você pode verificar o status do peer com o seguinte comando:
(nextcloud1)$ gluster peer status
Number of Peers: 2
Hostname: 192.168.0.22
Uuid: f9d2928a-6b64-455a-9e0e-654a1ebbc320
State: Peer in Cluster (Connected)
Hostname: 192.168.0.23
Uuid: 100b7778-459d-4c48-9ea8-bb8fe33d9493
State: Peer in Cluster (Connected)
Passo dez
No nextcloud1, crie um volume replicado nos nós testados:
(nextcloud1)$ gluster volume create rep-volume replica 3 192.168.0.21:/glusterfs/brick 192.168.0.22:/glusterfs/brick 192.168.0.23:/glusterfs/brick
volume create: rep-volume: success: please start the volume to access data
Passo Onze
Inicie o volume replicado em nextcloud1:
(nextcloud1)$ gluster volume start rep-volume
volume start: rep-volume: success
Verifique se o volume e os processos replicados estão online:
$ gluster volume status
Status of volume: rep-volume
Gluster process TCP Port RDMA Port Online Pid
------------------------------------------------------------------------------
Brick 192.168.0.21:/glusterfs/brick 49152 0 Y 32570
Brick 192.168.0.22:/glusterfs/brick 49152 0 Y 27175
Brick 192.168.0.23:/glusterfs/brick 49152 0 Y 25799
Self-heal Daemon on localhost N/A N/A Y 32591
Self-heal Daemon on 192.168.0.22 N/A N/A Y 27196
Self-heal Daemon on 192.168.0.23 N/A N/A Y 25820
Task Status of Volume rep-volume
------------------------------------------------------------------------------
There are no active volume tasks
Doze Passo
Monte o volume replicado em /var/www/html. Crie o diretório:
$ mkdir -p /var/www/html
Passo Treze
13) Adicione a seguinte linha em /etc/fstab para permitir a montagem automática:
/dev/sdb1 /glusterfs xfs defaults,defaults 0 0
localhost:/rep-volume /var/www/html glusterfs defaults,_netdev 0 0
Passo Quatorze
Monte o GlusterFS em /var/www/html:
$ mount -a
E verifique com:
$ mount | grep gluster
/dev/sdb1 on /glusterfs type xfs (rw,relatime,seclabel,attr2,inode64,noquota)
localhost:/rep-volume on /var/www/html type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
O volume replicado agora está pronto e montado em cada nó. Agora podemos prosseguir para implantar o aplicativo.
Implantação do aplicativo Nextcloud
As etapas a seguir devem ser executadas em nextcloud1, nextcloud2 e nextcloud3, a menos que especificado de outra forma.
Nextcloud requer PHP 7.2 e posterior e para distribuição CentOS, temos que habilitar vários repositórios como EPEL e Remi para simplificar o processo de instalação.
Primeiro passo
Se o SELinux estiver habilitado, desabilite-o primeiro:
$ setenforce 0
$ sed -i 's/^SELINUX=.*/SELINUX=permissive/g' /etc/selinux/config
Você também pode executar o Nextcloud com o SELinux habilitado seguindo este guia.
Passo Dois
Instale os requisitos do Nextcloud e ative o repositório Remi para PHP 7.2:
$ yum install -y epel-release yum-utils unzip curl wget bash-completion policycoreutils-python mlocate bzip2
$ yum install -y http://rpms.remirepo.net/enterprise/remi-release-7.rpm
$ yum-config-manager --enable remi-php72
Passo Três
Instale as dependências do Nextcloud, principalmente pacotes relacionados ao Apache e PHP 7.2:
$ yum install -y httpd php72-php php72-php-gd php72-php-intl php72-php-mbstring php72-php-mysqlnd php72-php-opcache php72-php-pecl-redis php72-php-pecl-apcu php72-php-pecl-imagick php72-php-xml php72-php-pecl-zip
Passo Quatro
Ative o Apache e inicie-o:
$ systemctl enable httpd.service
$ systemctl start httpd.service
Passo Cinco
Faça um link simbólico para o PHP usar o binário do PHP 7.2:
$ ln -sf /bin/php72 /bin/php
Passo Seis
No nextcloud1, baixe o Nextcloud Server daqui e extraia-o:
$ wget https://download.nextcloud.com/server/releases/nextcloud-17.0.0.zip
$ unzip nextcloud*
Etapa Sete
No nextcloud1, copie o diretório em /var/www/html e atribua a propriedade correta:
$ cp -Rf nextcloud /var/www/html
$ chown -Rf apache:apache /var/www/html
**Observe que o processo de cópia em /var/www/html levará algum tempo devido à replicação de volume GlusterFS.
Etapa Oito
Antes de prosseguirmos para abrir o assistente de instalação, temos que desabilitar a variável pxc_strict_mode para algo diferente de "ENFORCING" (o valor padrão). Isso se deve ao fato de que a importação do banco de dados Nextcloud terá um número de tabelas sem chave primária definida, o que não é recomendado para execução no Galera Cluster. Isso é explicado com mais detalhes na seção Tuning mais abaixo.
Para alterar a configuração com o ClusterControl, basta ir em Gerenciar -> Configurações -> Alterar/Definir Parâmetros:
Escolha todas as instâncias de banco de dados da lista e digite:
- Grupo:MYSQLD
- Parâmetro:pxc_strict_mode
- Novo valor:PERMISSIVO
O ClusterControl realizará as alterações necessárias em cada nó do banco de dados automaticamente. Se o valor puder ser alterado durante o tempo de execução, ele entrará em vigor imediatamente. O ClusterControl também configura o valor dentro do arquivo de configuração do MySQL para persistência. Você deverá ver o seguinte resultado:
Passo Nove
Agora estamos prontos para configurar nossa instalação do Nextcloud. Abra o navegador e vá para o servidor HTTP do nextcloud1 em http://192.168.0.21/nextcloud/ e você verá o seguinte assistente de configuração:
Configure a seção "Armazenamento e banco de dados" com o seguinte valor:
- Pasta de dados:/var/www/html/nextcloud/data
- Configure o banco de dados:MySQL/MariaDB
- Nome de usuário:nextcloud
- Senha:(a senha do usuário nextcloud)
- Banco de dados:nextcloud
- Host:192.168.0.10:6603 (o endereço IP virtual com porta ProxySQL)
Clique em "Finish Setup" para iniciar o processo de configuração. Aguarde até que termine e você será redirecionado para o painel Nextcloud para o usuário "admin". A instalação está agora concluída. A próxima seção fornece algumas dicas de ajuste para executar com eficiência com o Galera Cluster.
Ajuste do banco de dados Nextcloud
Chave primária
Ter uma chave primária em cada tabela é vital para a replicação do conjunto de gravação do Galera Cluster. Para uma tabela relativamente grande sem chave primária, uma grande transação de atualização ou exclusão bloquearia completamente seu cluster por muito tempo. Para evitar quaisquer peculiaridades e casos extremos, simplesmente certifique-se de que todas as tabelas estejam usando o mecanismo de armazenamento InnoDB com uma chave primária explícita (chave única não conta).
A instalação padrão do Nextcloud criará um monte de tabelas no banco de dados especificado e algumas delas não cumprem esta regra. Para verificar se as tabelas são compatíveis com o Galera, podemos executar a seguinte instrução:
mysql> SELECT DISTINCT CONCAT(t.table_schema,'.',t.table_name) as tbl, t.engine, IF(ISNULL(c.constraint_name),'NOPK','') AS nopk, IF(s.index_type = 'FULLTEXT','FULLTEXT','') as ftidx, IF(s.index_type = 'SPATIAL','SPATIAL','') as gisidx FROM information_schema.tables AS t LEFT JOIN information_schema.key_column_usage AS c ON (t.table_schema = c.constraint_schema AND t.table_name = c.table_name AND c.constraint_name = 'PRIMARY') LEFT JOIN information_schema.statistics AS s ON (t.table_schema = s.table_schema AND t.table_name = s.table_name AND s.index_type IN ('FULLTEXT','SPATIAL')) WHERE t.table_schema NOT IN ('information_schema','performance_schema','mysql') AND t.table_type = 'BASE TABLE' AND (t.engine <> 'InnoDB' OR c.constraint_name IS NULL OR s.index_type IN ('FULLTEXT','SPATIAL')) ORDER BY t.table_schema,t.table_name;
+---------------------------------------+--------+------+-------+--------+
| tbl | engine | nopk | ftidx | gisidx |
+---------------------------------------+--------+------+-------+--------+
| nextcloud.oc_collres_accesscache | InnoDB | NOPK | | |
| nextcloud.oc_collres_resources | InnoDB | NOPK | | |
| nextcloud.oc_comments_read_markers | InnoDB | NOPK | | |
| nextcloud.oc_federated_reshares | InnoDB | NOPK | | |
| nextcloud.oc_filecache_extended | InnoDB | NOPK | | |
| nextcloud.oc_notifications_pushtokens | InnoDB | NOPK | | |
| nextcloud.oc_systemtag_object_mapping | InnoDB | NOPK | | |
+---------------------------------------+--------+------+-------+--------+
A saída acima mostra que existem 7 tabelas que não possuem uma chave primária definida. Para corrigir o acima, basta adicionar uma chave primária com coluna de incremento automático. Execute os seguintes comandos em um dos servidores de banco de dados, por exemplo nexcloud1:
(nextcloud1)$ mysql -uroot -p
mysql> ALTER TABLE nextcloud.oc_collres_accesscache ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;
mysql> ALTER TABLE nextcloud.oc_collres_resources ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;
mysql> ALTER TABLE nextcloud.oc_comments_read_markers ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;
mysql> ALTER TABLE nextcloud.oc_federated_reshares ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;
mysql> ALTER TABLE nextcloud.oc_filecache_extended ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;
mysql> ALTER TABLE nextcloud.oc_notifications_pushtokens ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;
mysql> ALTER TABLE nextcloud.oc_systemtag_object_mapping ADD COLUMN `id` INT PRIMARY KEY AUTO_INCREMENT;
Uma vez aplicadas as modificações acima, podemos reconfigurar o pxc_strict_mode para o valor recomendado, "ENFORCING". Repita a etapa 8 na seção "Application Deployment" com o valor correspondente.
Nível de isolamento COMPROVADO DE LEITURA
O nível de isolamento de transação recomendado conforme recomendado pelo Nextcloud é usar READ-COMMITTED, enquanto o Galera Cluster é padrão para um nível de isolamento REPEATABLE-READ mais estrito. O uso de READ-COMMITTED pode evitar a perda de dados em cenários de alta carga (por exemplo, usando o cliente de sincronização com muitos clientes/usuários e muitas operações paralelas).
Para modificar o nível de transação, vá para ClusterControl -> Manage -> Configurations -> Change/Set Parameter e especifique o seguinte:
Clique em "Continuar" e o ClusterControl aplicará as alterações de configuração imediatamente. Não é necessário reiniciar o banco de dados.
Próxima nuvem de várias instâncias
Desde que realizamos a instalação no nextcloud1 ao acessar a URL, esse endereço IP é adicionado automaticamente na variável 'trusted_domains' dentro do Nextcloud. Ao tentar acessar outros servidores, por exemplo, o servidor secundário, http://192.168.0.22/nextcloud, você veria um erro informando que este host não está autorizado e deve ser adicionado à variável trusted_domain.
Portanto, adicione todos os endereços IP dos hosts no array "trusted_domain" dentro de /var/www/html/nextcloud/config/config.php, conforme exemplo abaixo:
'trusted_domains' =>
array (
0 => '192.168.0.21',
1 => '192.168.0.22',
2 => '192.168.0.23'
),
A configuração acima permite que os usuários acessem todos os três servidores de aplicativos por meio dos seguintes URLs:
- http://192.168.0.21/nextcloud (nextcloud1)
- http://192.168.0.22/nextcloud (nextcloud2)
- http://192.168.0.23/nextcloud (nextcloud3)
Observação:você pode adicionar uma camada de balanceador de carga sobre essas três instâncias do Nextcloud para obter alta disponibilidade para a camada de aplicativo usando proxies reversos HTTP disponíveis no mercado, como HAProxy ou nginx. Isso está fora do escopo desta postagem do blog.
Usando Redis para bloquear arquivos
O mecanismo de bloqueio de arquivos transacionais do Nextcloud bloqueia arquivos para evitar corrupção de arquivos durante a operação normal. Recomenda-se instalar o Redis para cuidar do bloqueio de arquivos transacionais (isso é ativado por padrão), o que aliviará o cluster de banco de dados de lidar com esse trabalho pesado.
Para instalar o Redis, basta:
$ yum install -y redis
$ systemctl enable redis.service
$ systemctl start redis.service
Anexar as seguintes linhas dentro de /var/www/html/nextcloud/config/config.php:
'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => array(
'host' => '192.168.0.21',
'port' => 6379,
'timeout' => 0.0,
),
Para obter mais detalhes, consulte esta documentação, Bloqueio de Arquivo Transacional.
Conclusão
O Nextcloud pode ser configurado para ser um serviço de hospedagem de arquivos escalável e altamente disponível para atender às suas demandas de compartilhamento de arquivos privados. Neste blog, mostramos como você pode trazer redundância nas camadas Nextcloud, sistema de arquivos e banco de dados.