ABBYY Vantage permite que você use pastas compartilhadas hospedadas no servidor do ABBYY Vantage para importar e exportar documentos e skills, bem como para atualizar catálogos de dados.
Antes de começar a usar pastas compartilhadas (compartilhamento NFS), é necessário configurar, em um computador cliente, uma conexão com essas pastas compartilhadas. Execute as etapas a seguir em um computador cliente com Windows:
- Execute o Windows PowerShell como administrador.
- Instale o Cliente NFS do Windows:
dism /online /Enable-Feature /FeatureName:ServicesForNFS-ClientOnly
dism /online /Enable-Feature /FeatureName:ClientForNFS-Infrastructure
- Configure o mapeamento de usuários do Windows para UIDs e GIDs do Unix, de acordo com as políticas da sua empresa:
New-ItemProperty -Path "HKLM:\Software\Microsoft\ClientForNFS\CurrentVersion\Default" -Name "AnonymousGid" -Value 65532 -PropertyType DWord
New-ItemProperty -Path "HKLM:\Software\Microsoft\ClientForNFS\CurrentVersion\Default" -Name "AnonymousUid" -Value 65532 -PropertyType DWord
- Reinicie o cliente NFS:
nfsadmin client stop
nfsadmin client start
Depois de concluir as etapas acima, você poderá copiar e usar os caminhos de pastas compartilhadas no Vantage, bem como abri-los no Explorador de Arquivos.
ABBYY Vantage usa bancos de dados hospedados em servidores externos e pode ficar inoperante se esses servidores falharem. O administrador do sistema pode restaurar esses bancos de dados em um servidor diferente e configurar uma conexão com os novos bancos de dados usando o Consul.
Antes de começar, verifique se a ferramenta de linha de comando kubectl está instalada e se uma conexão com o cluster Kubernetes foi estabelecida.
Para configurar uma conexão com um novo banco de dados nas configurações do ABBYY Vantage:
- Acesse a interface web do Consul executando o comando a seguir:
kubectl port-forward -n abbyy-infrastructure service/consul-ui 8500:80
Em seguida, acesse http://localhost:8500/ui/dc1/kv/secret/.
- Use a guia Key/Value que será exibida para selecionar o ambiente Vantage correto.
- Selecione o projeto platform ou vantage, bem como o serviço apropriado que usa o banco de dados (por exemplo, mail).
- Acesse a seção database que cada serviço contém.
- Abra a seção SqlServer.
- Na chave connectionString:
- Substitua o valor antigo de Server pelo endereço do novo servidor
- Especifique o novo banco de dados no parâmetro Database
- Especifique as credenciais de login nos parâmetros User Id e Password
- Clique em Save.
- Reinicie o serviço modificado executando o seguinte comando:
label=mail
kubectl -n abbyy-vantage rollout restart $(kubectl -n abbyy-vantage get deployments -l app.kubernetes.io/component=$label -o name)
Sempre que o endereço do servidor for alterado, este procedimento deverá ser executado para cada banco de dados.
Referência dos Serviços de Banco de Dados
A tabela abaixo lista todos os serviços que utilizam o banco de dados, bem como o rótulo usado para reiniciar cada serviço.
| Nome da seção no Consul | Rótulo do serviço | Observações |
|---|
| api-gateway-registry | api-gateway-registry | |
| api-registry | api-registry | |
| auth-adminapi2 | auth-adminapi2 | |
| auth-identity | auth-identity | |
| auth | auth-sts-identity, auth-adminapi2 | Este banco de dados é utilizado por dois serviços |
| blob-storage | blob-storage | |
| cron-service | cron-service | |
| documentsetstorage | documentsetstorage | |
| mail | mail | |
| security-audit | security-audit | |
| storage | storage | A seção de banco de dados é armazenada no catálogo de dados fileMetadata |
| workflow-facade | workflow-facade | |
| workflow-scheduler | workflow-scheduler | |
| Nome da seção no Consul | Rótulo do serviço |
|---|
| catalogstorage | catalogstorage |
| folderimport | folderimport |
| interactive-jobs | interactive-jobs |
| mailimport | mailimport |
| permissions | permissions |
| publicapi | publicapi |
| reporting | reporting |
| secretstorage | secretstorage |
| skill-monitor | skill-monitor |
| skillinfo | skillinfo |
| subscriptions | subscriptions |
| tokenmanagement | tokenmanagement |
| transactions | transactions |
| workspace | workspace |
O Vantage permite usar a GPU para treinar skills usando a atividade Deep Learning para extrair dados de documentos semiestruturados.
Requisitos de sistema para GPU
- Memória RAM mínima da GPU virtual: 12 GB
- 1 CPU e 4 GB de RAM para cada GPU virtual no host (por exemplo, uma VM com uma única GPU virtual de 12 GB deve ter pelo menos 2 CPUs e 8 GB de RAM)
Você pode usar uma GPU virtual (vGPU) para dividir uma GPU física em várias máquinas virtuais, permitindo que os recursos do Vantage sejam utilizados com mais eficiência.
Para configurar a vGPU:
- Copie o pacote de drivers NVIDIA GRID do hub de aplicativos da NVIDIA para uma máquina virtual com GPU e execute os seguintes comandos:
apt-get update
apt-get install dkms
dpkg -i nvidia-linux-grid-535_535.54.03_amd64.deb
-
Instale o operador de GPU NVIDIA no cluster do Kubernetes:
a. Coloque o arquivo de token de licença (gerado no NVIDIA Application Hub) na pasta
$PWD/gpu/ antes de executar o contêiner do instalador do Vantage.
b. Adicione o parâmetro -v $PWD/gpu:/ansible/files/gpu:ro ao comando para executar o contêiner do instalador do Vantage:
docker run -it \
-v $PWD/kube:/root/.kube \
-v $PWD/ssh/ansible:/root/.ssh/ansible \
-v "//var/run/docker.sock:/var/run/docker.sock" \
-v $PWD/inventory:/ansible/inventories/k8s/inventory \
-v $PWD/env_specific.yml:/ansible/inventories/k8s/group_vars/all/env_specific.yml \
-v $PWD/ssl:/ansible/files/ssl:ro \
-v $PWD/gpu:/ansible/files/gpu:ro \
--privileged \
registry.local/vantage/vantage-k8s:2.7.1
c. Adicione um nó de GPU ao arquivo de inventário, no grupo [abbyy_workers]. O nome da máquina virtual com a GPU deve incluir “gpu”:
[abbyy_workers]
worker16-48-w01 ansible_host=10.10.10.27
worker16-48-w02 ansible_host=10.10.10.21
worker16-48-w03 ansible_host=10.10.10.20
worker2-12-a40-gpu01 ansible_host=10.10.10.60
d. Adicione um nó ao cluster executando o seguinte playbook:
chmod 600 /root/.ssh/ansible
ansible-playbook -i inventories/k8s -v playbooks/4-Kubernetes-k8s.yml
- Configure a vGPU executando o seguinte playbook:
ansible-playbook -i inventories/k8s -v playbooks/setup-gpu-node.yml
Você pode configurar o pass-through de GPU, que dá a uma máquina virtual acesso direto à sua GPU.
Para configurar o pass-through de GPU:
- Execute o container do instalador do Vantage:
docker run -it \
-v $PWD/kube:/root/.kube \
-v $PWD/ssh/ansible:/root/.ssh/ansible \
-v "//var/run/docker.sock:/var/run/docker.sock" \
-v $PWD/inventory:/ansible/inventories/k8s/inventory \
-v $PWD/env_specific.yml:/ansible/inventories/k8s/group_vars/all/env_specific.yml \
-v $PWD/ssl:/ansible/files/ssl:ro \
--privileged \
registry.local/vantage/vantage-k8s:2.7.1
- Adicione um nó de GPU (por exemplo, worker2-12-a40-gpu01) ao arquivo de inventário no grupo
[abbyy_workers]:
[abbyy_workers]
worker16-48-w01 ansible_host=10.10.10.27
worker16-48-w02 ansible_host=10.10.10.21
worker16-48-w03 ansible_host=10.10.10.20
worker2-12-a40-gpu01 ansible_host=10.10.10.60
- Execute o playbook:
ansible-playbook -i inventories/k8s -v playbooks/4-Kubernetes-k8s.yml
- Instale o Helm chart do operador de GPU:
helm upgrade --install gpu-operator ansible/files/helm/charts/gpu-operator --create-namespace --debug -n gpu-operator
- Adicione um taint ao nó:
kubectl taint nodes worker2-12-a40-gpu01 nvidia.com/gpu:NoSchedule
Testando e implantando GPU
Para testar a instalação de um operador de GPU em ambos os modos vGPU e GPU passthrough:
- Execute este comando:
kubectl apply -f filename
- Crie um arquivo YAML com o conteúdo a seguir e aplique-o:
apiVersion: v1
kind: Pod
metadata:
name: gpu-pod
namespace: gpu-operator
spec:
restartPolicy: Never
containers:
- name: cuda-container
image: nvcr.io/nvidia/k8s/cuda-sample:vectoradd-cuda10.2
resources:
limits:
nvidia.com/gpu: 1 # solicitando 1 GPU
tolerations:
- key: nvidia.com/gpu
operator: Exists
effect: NoSchedule
- key: k8s.abbyy.com/techcore
effect: NoSchedule
value: "true"
- Verifique o log do pod. Você deverá ver uma resposta contendo
Test PASSED:
kubectl -n gpu-operator logs gpu-pod
Resultado esperado:
[Vector addition of 50000 elements]
Copy input data from the host memory to the CUDA device
CUDA kernel launch with 196 blocks of 256 threads
Copy output data from the CUDA device to the host memory
Test PASSED
Done
Para implantar o worker de GPU:
- Adicione os seguintes parâmetros ao arquivo
env_specific.yml:
techcore:
use_gpu_workers: true
use_nn_extraction_training_workers: true
- Execute uma das seguintes ações:
- Se o Vantage já estiver instalado, execute o seguinte playbook para implantar workers de GPU:
ansible-playbook -i inventories/k8s -v playbooks/11-DeployWorkers-k8s.yml
- Se o Vantage ainda não estiver instalado, os workers de GPU serão implantados durante a instalação.
Configurando um tempo limite de inatividade para revisão manual
Na revisão manual, se nenhuma ação for realizada pelo operador durante um período de 15 minutos em uma tarefa aberta, ocorre um tempo limite. O Administrador do Sistema pode alterar o período de inatividade necessário para que o tempo limite seja acionado usando o Consul.
Para configurar o tempo limite:
- Acesse a interface web do Consul executando:
kubectl port-forward -n abbyy-infrastructure service/consul-ui 8500:80
Then navigate to http://localhost:8500/ui/dc1/kv/secret/.
- Use the Key/Value tab to select the correct Vantage environment.
- Change the values of the following keys:
| Key | Description |
|---|
secret/abbyy-vantage/vantage/verification/interactiveJobsOptions/popTimeout | O período mínimo em que um usuário permanece inativo antes que uma tarefa seja devolvida para a fila de tarefas interativas. Qualquer ação interativa (movimento do mouse, entrada pelo teclado, processamento de patches etc.) redefine a contagem regressiva. Padrão: 00:15:00 (15 minutos) |
secret/abbyy-vantage/vantage/verification/interactiveJobsOptions/processingPopTimeout | O período mínimo de inatividade do usuário após o qual a tarefa será devolvida à fila se houver operações de longa duração (aplicar uma skill, virar páginas etc.). Quando uma operação de longa duração é iniciada, esse valor é definido como o período máximo de inatividade permitido. Quando a operação é concluída, o período de inatividade é redefinido para o valor de popTimeout. Padrão: 1.00:00:00 (24 horas) |
- Click Save.
- Restart the verification and manualverification services:
kubectl -n abbyy-vantage rollout restart $(kubectl -n abbyy-vantage get deployments -l app.kubernetes.io/component=verification -o name)
kubectl -n abbyy-vantage rollout restart $(kubectl -n abbyy-vantage get deployments -l app.kubernetes.io/component=manualverification -o name)
Atualizando o certificado SSL
Quando o certificado SSL expirar, será necessário atualizá-lo para o novo certificado.
- Vá para Config > Secrets e localize todos os segredos chamados
platform-wildcard.
- Para cada segredo, vá até a subseção Data, clique no ícone Show e atualize os valores:
- Insira o valor do novo certificado no campo
tls.crt
- Insira o valor da respectiva chave no campo
tls.key
O certificado e a chave devem ser arquivos PEM com o conteúdo codificado em ASCII base64 (PKCS#8). Eles devem começar com -----BEGIN CERTIFICATE----- para o certificado e -----BEGIN PRIVATE KEY----- para a chave.
- Clique em Save.
Usando a linha de comando do Linux
- Certifique-se de ter acesso ao cluster Kubernetes:
- Coloque o certificado e a chave em formato PEM no diretório atual:
cert.pem, key.pem.
Converta o arquivo CRT para o formato PEM se necessário:
-----BEGIN CERTIFICATE-----
[your certificate]
-----END CERTIFICATE-----
-----BEGIN PRIVATE KEY-----
[your key]
-----END PRIVATE KEY-----
- Execute os seguintes comandos:
for i in `kubectl get secret --field-selector metadata.name=platform-wildcard -o custom-columns=:metadata.namespace -A --no-headers 2>/dev/null`; do kubectl patch secret platform-wildcard -p "{\"data\":{\"tls.key\":\"$(base64 < "./key.pem" | tr -d '\n')\", \"tls.crt\":\"$(base64 < "./cert.pem" | tr -d '\n')\"}}" -n $i; done
kubectl rollout restart deployment -n abbyy-infrastructure $(kubectl get deployment -n abbyy-infrastructure -o custom-columns=NAME:metadata.name --no-headers 2>/dev/null | grep ingress-nginx-controller)