Já falamos sobre como / por que gostamos do Rook: em grande parte, simplifica o trabalho com o armazenamento em clusters do Kubernetes. No entanto, com essa simplicidade, algumas dificuldades surgem. Esperamos que o novo material ajude a entender melhor essas dificuldades antes mesmo que elas se manifestem.
E para ler isso foi mais interessante, começamos com as
consequências de um problema hipotético no cluster.
"Tudo se foi!"
Imagine que uma vez você configurou e lançou o Rook no cluster do K8s, ele ficou satisfeito com o trabalho dele, mas em algum momento “maravilhoso” acontece o seguinte:
- Novos pods não podem montar Ceph RBDs.
- Comandos como
lsblk e df não funcionam em hosts Kubernetes. Isso significa automaticamente "algo está errado" com as imagens RBD montadas no nó. Não consigo lê-los, o que indica a inacessibilidade dos monitores ... - Sim, não há monitores operacionais no cluster. Além disso - nem existem pods com OSD, nem pods de MGR.
Quando foi lançado o pod
rook-ceph-operator ? Não faz muito tempo que ele foi destacado. Porque O operador da torre decidiu criar um novo cluster ... Como podemos agora restaurar o cluster e os dados nele?
Para começar, vamos seguir um caminho
mais interessante, depois de realizar uma investigação cuidadosa sobre os "internos" do Rook e uma restauração passo a passo de seus componentes. Obviamente, existe uma maneira correta
mais curta : usar backups. Como você sabe, os administradores são divididos em dois tipos: aqueles que não fazem backups e aqueles que já os fazem ... Mas mais sobre isso após a investigação.
Um pouco de prática ou um longo caminho
Dê uma olhada e restaure os monitores
Portanto, vejamos a lista de ConfigMaps: existem
rook-ceph-config e
rook-config-override necessários para o backup. Eles aparecem após a implantação bem-sucedida do cluster.
Nota : em novas versões, após a adoção deste PR , o ConfigMaps deixou de ser um indicador do sucesso de uma implantação de cluster.Para executar outras ações, precisamos de uma reinicialização total de todos os servidores que montaram imagens RBD (
ls /dev/rbd* ). Isso deve ser feito através do sysrq (ou "a pé" no datacenter). Esse requisito é causado pela tarefa de desconectar RBDs montados, para os quais uma reinicialização regular não funcionará (tentará desmontá-los normalmente sem êxito).
O teatro começa com um cabide, e o cluster Ceph começa com monitores. Vamos olhar para eles.
A torre monta as seguintes entidades no pod do monitor:
Volumes: rook-ceph-config: Type: ConfigMap (a volume populated by a ConfigMap) Name: rook-ceph-config rook-ceph-mons-keyring: Type: Secret (a volume populated by a Secret) SecretName: rook-ceph-mons-keyring rook-ceph-log: Type: HostPath (bare host directory volume) Path: /var/lib/rook/kube-rook/log ceph-daemon-data: Type: HostPath (bare host directory volume) Path: /var/lib/rook/mon-a/data Mounts: /etc/ceph from rook-ceph-config (ro) /etc/ceph/keyring-store/ from rook-ceph-mons-keyring (ro) /var/lib/ceph/mon/ceph-a from ceph-daemon-data (rw) /var/log/ceph from rook-ceph-log (rw)
Vamos ver qual é o segredo do
rook-ceph-mons-keyring :
kind: Secret data: keyring: LongBase64EncodedString=
Decodificamos e obtemos o chaveiro usual com direitos para o administrador e monitores:
[mon.] key = AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA== caps mon = "allow *" [client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Lembre-se. Agora veja o chaveiro no segredo
rook-ceph-admin-keyring :
kind: Secret data: keyring: anotherBase64EncodedString=
O que há nele?
[client.admin] key = AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
O mesmo. Vamos ver mais ... Aqui, por exemplo, está o segredo do
rook-ceph-mgr-a-keyring :
[mgr.a] key = AQBZR19dbVeaIhBBXFYyxGyusGf8x1bNQunuew== caps mon = "allow *" caps mds = "allow *" caps osd = "allow *"
No final, encontramos mais alguns segredos no ConfigMap
rook-ceph-mon :
kind: Secret data: admin-secret: AQAhT19d9MMEMRGG+wxIwDqWO1aZiZGcGlSMKp== cluster-name: a3ViZS1yb29r fsid: ZmZiYjliZDMtODRkOS00ZDk1LTczNTItYWY4MzZhOGJkNDJhCg== mon-secret: AQAhT19dlUz0LhBBINv5M5G4YyBswyU43RsLxA==
E esta é a lista inicial com chaveiro, de onde vêm todos os segredos descritos acima.
Como você sabe (consulte
dataDirHostPath na
documentação ), a Rook armazena esses dados em dois locais. Portanto, vamos aos nós para examinar o conjunto de chaves nos diretórios montados em pods com monitores e OSD. Para fazer isso, localize os nós
/var/lib/rook/mon-a/data/keyring e consulte:
# cat /var/lib/rook/mon-a/data/keyring [mon.] key = AXAbS19d8NNUXOBB+XyYwXqXI1asIzGcGlzMGg== caps mon = "allow *"
De repente, o segredo acabou sendo diferente - não como no ConfigMap.
E o chaveiro de administrador? Nós também temos:
# cat /var/lib/rook/kube-rook/client.admin.keyring [client.admin] key = AXAbR19d8GGSMUBN+FyYwEqGI1aZizGcJlHMLgx= caps mds = "allow *" caps mon = "allow *" caps osd = "allow *" caps mgr = "allow *"
Aqui está o problema. Houve um fracasso: o cluster foi recriado ... mas na realidade não.
Torna-se claro que o chaveiro recém-gerado é armazenado em segredos e não é do nosso cluster antigo. Portanto:
- usamos o chaveiro do monitor no arquivo
/var/lib/rook/mon-a/data/keyring (ou no backup); - mude o chaveiro no segredo
rook-ceph-mons-keyring ; - registre o chaveiro do administrador e o monitor no ConfigMap'e
rook-ceph-mon ; - remova os controladores de pod com monitores.
O milagre não vai demorar muito: os monitores aparecerão e iniciarão. Viva, um começo!
Restaurar OSD
Entramos no
rook-operator pod: chamar
ceph mon dump mostra que todos os monitores estão no lugar e
ceph -s que eles estão em um quorum. No entanto, se você olhar para a árvore OSD (
ceph osd tree ), verá algo estranho: os OSDs começaram a aparecer, mas estão vazios. Acontece que eles também precisam ser restaurados de alguma forma. Mas como
Enquanto isso,
rook-ceph-config e
rook-config-override , bem como muitos outros ConfigMaps com nomes no formato
rook-ceph-osd-$nodename-config , apareceram no ConfigMap tão necessário. Vamos olhar para eles:
kind: ConfigMap data: osd-dirs: '{"/mnt/osd1":16,"/mnt/osd2":18}'
Tudo está errado, tudo está confuso!
Escale o pod do operador para zero, exclua os pods de implantação gerados no OSD e corrija esses ConfigMaps. Mas onde obter o mapa OSD
correto por nós?
- Vamos tentar nos aprofundar nos diretórios
/mnt/osd[1-2] nos nós novamente - na esperança de que possamos encontrar algo lá. - Existem 2 subdiretórios no diretório
/mnt/osd1 : osd0 e osd16 . O último é exatamente o ID especificado no ConfigMap (16)? - Vamos
osd0 tamanho e ver que osd0 muito maior que osd16 .
Concluímos que
osd0 é o OSD necessário, que foi especificado como
/mnt/osd1 no ConfigMap (porque usamos o
osd baseado em diretório )
Passo a passo, verificamos todos os nós e editamos o ConfigMap. Após todas as instruções, você pode executar o pod do operador Rook e ler seus logs. E tudo é maravilhoso neles:
- Eu sou um operador de cluster;
- Encontrei unidades em nós;
- Eu encontrei monitores;
- os monitores tornaram-se amigos, ou seja, formou um quorum;
- executando implantações OSD ...
Vamos voltar ao pod do operador Rook e verificar a vitalidade do cluster ... sim, cometemos um pequeno erro com as conclusões sobre os nomes OSD em alguns nós! Não importa: eles novamente corrigiram o ConfigMaps, excluíram os diretórios extras dos novos OSDs e chegaram ao estado tão esperado de
HEALTH_OK !
Confira as imagens na piscina:
Tudo está no lugar - o cluster está salvo!
Estou com preguiça de fazer backups, ou o Fast Way
Se os backups foram feitos para o Rook, o procedimento de recuperação se torna muito mais simples e se resume ao seguinte:
- Escalar para implantação zero do operador Rook;
- Removemos todas as implantações, exceto o operador Rook;
- Restauramos todos os segredos e ConfigMaps do backup;
- Restaure o conteúdo dos
/var/lib/rook/mon-* nos nós; - Restauração (se perdida repentinamente) CRD
CephCluster , CephFilesystem , CephBlockPool , CephNFS , CephObjectStore ; - Escale a implantação do operador Rook de volta para 1.
Dicas úteis
Faça backups!
E para evitar situações em que você precisa se recuperar delas:
- Antes de trabalhar em larga escala com o cluster, consistindo em reinicializações do servidor, dimensione o operador Rook para zero para que ele não faça muito.
- Nos monitores, adicione nodeAffinity antecipadamente.
- Preste atenção ao pré- definir os tempos limite
ROOK_MON_HEALTHCHECK_INTERVAL e ROOK_MON_OUT_TIMEOUT .
Em vez de uma conclusão
Não faz sentido argumentar que Rook, sendo uma "camada" adicional (no esquema geral de organização de armazenamento no Kubernetes), simplifica muito, mas também adiciona novas dificuldades e possíveis problemas na infraestrutura. A coisa permanece "pequena": fazer uma escolha equilibrada e informada entre esses riscos, por um lado, e os benefícios que a solução traz em seu caso particular, por outro.
A propósito, a seção “Adotar um cluster Rook Ceph existente em um novo cluster Kubernetes” foi recentemente
adicionada à documentação
do Rook. Ele descreve com mais detalhes o que precisa ser feito para mover os dados existentes para um novo cluster do Kubernetes ou restaurar um cluster que foi recolhido por um motivo ou outro.
PS
Leia também em nosso blog: