Orchest - Out Of Memory

[rafaelsantanaep]

@beatrizaantunes @cicerojmm @allansene

Derrubei a pouco o orchest de process, não entendi ainda porque ele caiu, porque o código que estava sendo executando deveria ser executado somente no snowflake:

from dadosfera import snowflake as dadosfera_snowflake

snowpark = dadosfera_snowflake.get_snowpark_session('prd/root/snowflake_credentials/data_marketplace_producer')
snowpark.use_schema('raw')

def main():

    datasets = ['exportacao_consolidada']

    for dataset in datasets:

        with open(f'/project-dir/queries/{dataset}.sql') as f:
            query = f.read()

        df = snowpark.sql(query)

    df.write.mode('overwrite').save_as_table(f'comercio_exterior.{dataset}')

main()

Fiquei esperando pra ver se o kubernetes recriava a máquina, mas ele não tava conseguindo decomissionar a máquina. Executei o seguinte processo que conseguiu normalizar o orchest:

Pra pegar o nome do nó:

kubectl get nodes

Pra forçar o delete do nó:

kubectl cordon <node_name>
kubectl delete node <node_name>

Mesmo com esse comando que utilizei, o kubernetes não tava conseguindo matar o nó e isso foi observado pelos eventos do kubernets:

Matei o nó diretamente pelo console da AWS e, com isso, o kubernetes conseguiu recriar o nó. Como pode ser observado abaixo:

Com isso, o orchest subiu com alguns probleminhas. Para resolvê-los, eu restartei o orchest pela interface e, com isso, só restartei a sessão do projeto que eu estava utilizando e foi possível abrir o jupyter notebook normalmente.

Acho que podemos adotar isso como procedimento padrão quando isso ocorrer.

[beatrizaantunes]

Boa Santana! fyi @oliveira-devops Pelo o que entendi já está resolvido então né, só documentar na platform-docs. @oliveira-devops pode centralizar lá por favor?

[rafaelsantanaep]

@beatrizaantunes Sim. Só um detalhe que ficou de fora da documentação. Existe o risco da máquina ser recriada em uma outra zona de disponibilidadede. Nesse caso, a máquina teria que ser morta novamente porque o EKS não conseguiria attachar o EBS na nova máquina. Isso ocorre porque o node group ta configurado com duas zonas de disponibilidade. O Alex na época do repasse não sabia se ele tinha feito assim porque era requerido ou porque ele n tinha conhecimento que isso podia dar merda.

Acho que vale mais pra frente a gente testar se é possível limitar o node group pra uma zona de disponibilidade porque isso diminuiria a quantidade de vezes que a máquina é recriada com problema.

[rafaelsantanaep]

Esse mesmo cenário também pode ocorrer no momento que a gente tenta restaurar um EKS utilizando o Velero (a ferramenta de disaster recovery que o Alex implementou).

[allansene]

@oliveira-devops para fechar, documentar na Wiki da Bugsfera este workaround/diagnostico

[oliveira-devops]

Documentado na Wiki da Bugsfera:

https://github.com/dadosfera/Bugsfera/wiki/Orchest#out-of-memory

[beatrizaantunes]

Comecei a referenciar tudo do Orchest na Wiki (Google) aqui: https://sites.google.com/dadosfera.ai/wikisuportedadosfera/documenta%C3%A7%C3%A3o/orchest