Notas de versão do Azure Stack Edge 2403
APLICA-SE A:
Azure Stack Edge Pro - GPUAzure Stack Edge Pro 2Azure Stack Edge Pro RAzure Stack Edge Mini R
As notas de versão a seguir identificam problemas críticos em aberto e problemas resolvidos para a versão 2403 para seus dispositivos Azure Stack Edge. Os recursos e problemas que correspondem a um modelo específico do Azure Stack Edge são destacados sempre que aplicável.
As notas de versão são atualizadas continuamente e, à medida que problemas críticos que exigem uma solução alternativa são descobertos, elas são adicionadas. Antes de implantar seu dispositivo, revise cuidadosamente as informações contidas nas notas de versão.
Este artigo aplica-se à versão do Azure Stack Edge 2403, que mapeia para a versão de software 3.2.2642.2487.
Aviso
Nesta versão, você deve atualizar a versão do núcleo do pacote para AP5GC 2308 antes de atualizar para o Azure Stack Edge 2403. Para obter etapas detalhadas, consulte Notas de versão do Azure Private 5G Core 2308. Se você atualizar para o Azure Stack Edge 2403 antes de atualizar para o Packet Core 2308.0.1, ocorrerá uma interrupção total do sistema. Nesse caso, você deve excluir e recriar o cluster de serviço do Azure Kubernetes em seu dispositivo Azure Stack Edge. Sempre que você alterar o perfil de carga de trabalho do Kubernetes, será solicitada a atualização do Kubernetes. Vá em frente e aplique a atualização.
Caminhos de atualização suportados
Para aplicar a atualização 2403, seu dispositivo deve estar executando a versão 2303 ou posterior.
Se você não estiver executando a versão mínima necessária, verá este erro:
O pacote de atualização não pode ser instalado porque suas dependências não são atendidas.
Pode atualizar para 2303 a partir de 2207 ou posterior e, em seguida, atualizar para 2403.
Você pode atualizar para a versão mais recente usando os seguintes caminhos de atualização:
| Versão atual do software Azure Stack Edge e Kubernetes | Atualização para o software Azure Stack Edge e Kubernetes | Atualização desejada para 2403 |
|---|---|---|
| 2207 | 2303 | 2403 |
| 2209 | 2303 | 2403 |
| 2210 | 2303 | 2403 |
| 2301 | 2303 | 2403 |
| 2303 | Diretamente para | 2403 |
Novidades
A versão 2403 tem os seguintes novos recursos e aprimoramentos:
- Suporte preterido para telemetria de serviço do Azure Kubernetes no Azure Stack Edge.
- Suporte de rótulo de zona para clusters Kubernetes de dois nós.
- Gerenciamento de VM Hyper-V, monitoramento de uso de memória no host Azure Stack Edge.
Problemas corrigidos nesta versão
| N.º | Caraterística | Problema |
|---|---|---|
| 1. | Clustering | A inicialização a frio de dois nós do servidor faz com que os recursos de cluster de VM de alta disponibilidade fiquem offline. Alterado ColdStartSetting para AlwaysStart. |
| 2. | Suporte de imagem do Marketplace | Corrigido o bug que permitia a imagem do Windows Marketplace no Azure Stack Edge A e TMA. |
| 3. | Conectividade de rede | Link NIC de VM fixo batendo após o desligamento/ativação do host do Azure Stack Edge, o que pode fazer com que a VM perca seu IP DHCP. |
| 4. | Conectividade de rede | Devido às configurações de proxy ARP em alguns ambientes de clientes, a verificação de endereço IP em uso retorna falso positivo, mesmo que nenhum ponto de extremidade na rede esteja usando o IP. A correção ignora o endereço IP da VM baseado em ARP em uso , verifique se o endereço IP está alocado de uma rede interna gerenciada pelo Azure Stack Edge. |
| 5. | Conectividade de rede | A operação de alteração da VM NIC expira após 3 horas, o que bloqueia outras operações de atualização da VM. Em clusters do Microsoft Kubernetes, os pods dependentes de Volume Persistente (PV) ficam presos. O problema ocorre quando várias NICs dentro de uma VM estão sendo transferidas de uma rede virtual VLAN para uma rede virtual não-VLAN. Após a correção, a operação de alteração da NIC da VM expira rapidamente e a atualização da VM não será bloqueada. |
| 6. | Kubernetes | Melhorias gerais na resiliência do Kubernetes de dois nós, como o aumento da memória para o plano de controle para o cluster de carga de trabalho AKS, o aumento dos limites para suporte etcd, multiréplica e antiafinidade rígida para pods de controlador csi de disco do DNS principal e do Azure e melhora os tempos de failover de VM. |
| 7. | Diagnóstico e atualização de computação | Correções de resiliência |
| 8. | Segurança | Correções de segurança STIG para o Mariner Guest OS para o serviço Kubernetes do Azure no Azure Stack Edge. |
| 9. | Operações VM | Em um cluster do Azure Stack Edge que implanta uma carga de trabalho AP5GC, após um teste de ciclo de energia do host, quando o host retorna um erro transitório sobre a configuração do grupo de CPU, o AzSHostAgent falharia. Isso causou uma falha nas operações da VM. A correção tornou o AzSHostAgent resiliente a um erro transitório do grupo de CPU. |
Problemas conhecidos nesta versão
| N.º | Caraterística | Problema | Solução alternativa/comentários |
|---|---|---|---|
| 1. | Explorador de Armazenamento do Azure | O certificado de ponto de extremidade de armazenamento de Blob gerado automaticamente pelo dispositivo Azure Stack Edge pode não funcionar corretamente com o Gerenciador de Armazenamento do Azure. | Substitua o certificado de ponto de extremidade de armazenamento de Blob. Para obter etapas detalhadas, consulte Traga seus próprios certificados. |
| 2. | Conectividade de rede | Em um cluster Azure Stack Edge Pro 2 de dois nós com um comutador virtual agrupado para a Porta 1 e a Porta 2, se um link da Porta 1 ou da Porta 2 estiver inativo, pode levar até 5 segundos para retomar a conectividade de rede na porta ativa restante. Se um cluster Kubernetes usar esse comutador virtual agrupado para gerenciamento de tráfego, a comunicação do pod poderá ser interrompida em até 5 segundos. | |
| 3. | Máquina virtual | Depois que a VM do pool de nós do host ou do Kubernetes for encerrada, há uma chance de que o kubelet na VM do pool de nós não seja iniciado devido a um erro de política estática da CPU. A VM do pool de nós mostra o status Não pronto e os pods não serão agendados nessa VM. | Insira uma sessão de suporte e ssh na VM do pool de nós e, em seguida, siga as etapas em Alterando a política do CPU Manager para corrigir o serviço kubelet. |
Problemas conhecidos de versões anteriores
A tabela a seguir fornece um resumo dos problemas conhecidos transferidos das versões anteriores.
| N.º | Caraterística | Problema | Solução alternativa/comentários |
|---|---|---|---|
| 1. | Azure Stack Edge Pro + Azure SQL | A criação de banco de dados SQL requer acesso de administrador. | Execute as etapas a seguir em vez das etapas 1 a 2 em Create-the-sql-database. 1. Na interface do usuário local do seu dispositivo, ative a interface de computação. Selecione Compute > Port # > Enable for compute > Apply. 2. Faça o download sqlcmd em sua máquina cliente do utilitário de comando SQL. 3. Conecte-se ao seu endereço IP da interface de computação (a porta que foi ativada), adicionando um ",1401" ao final do endereço. 4. O comando final é assim: sqlcmd -S {Interface IP},1401 -U SA -P "Forte! Passw0rd". Depois disso, as etapas 3 a 4 da documentação atual devem ser idênticas. |
| 2. | Atualizar | NÃO há suporte para alterações incrementais em blobs restaurados por meio de Atualização | Para pontos de extremidade de Blob, atualizações parciais de blobs após uma Atualização podem fazer com que as atualizações não sejam carregadas na nuvem. Por exemplo, sequência de ações como: 1. Crie blob na nuvem. Ou exclua um blob carregado anteriormente do dispositivo. 2. Atualize o blob da nuvem para o dispositivo usando a funcionalidade de atualização. 3. Atualize apenas uma parte do blob usando APIs REST do SDK do Azure. Essas ações podem fazer com que as seções atualizadas do blob não sejam atualizadas na nuvem. Solução alternativa: use ferramentas como roboscopia ou cópia regular de arquivos por meio do Explorer ou da linha de comando para substituir blobs inteiros. |
| 3. | Limitação | Durante a limitação, se novas gravações no dispositivo não forem permitidas, as gravações pelo cliente NFS falharão com um erro "Permissão negada". | O erro mostra como abaixo:hcsuser@ubuntu-vm:~/nfstest$ mkdir testmkdir: não é possível criar o diretório 'test': Permissão negada |
| 4. | Ingestão de Blob Storage | Ao usar AzCopy versão 10 para ingestão de armazenamento de Blob, execute AzCopy com o seguinte argumento: Azcopy <other arguments> --cap-mbps 2000 |
Se esses limites não forem fornecidos para o AzCopy, ele poderá enviar um grande número de solicitações para o dispositivo, resultando em problemas com o serviço. |
| 5. | Contas de armazenamento hierárquico | O seguinte se aplica ao usar contas de armazenamento hierárquico: - Apenas blobs de bloco são suportados. Não há suporte para blobs de página. - Não há suporte a snapshot ou copy API. - A ingestão de carga de trabalho do Hadoop não distcp é suportada, pois usa muito a operação de cópia. |
|
| 6. | Conexão de compartilhamento NFS | Se vários processos estiverem copiando para o mesmo compartilhamento e o nolock atributo não for usado, você poderá ver erros durante a cópia. |
O nolock atributo deve ser passado para o comando mount para copiar arquivos para o compartilhamento NFS. Por exemplo: C:\Users\aseuser mount -o anon \\10.1.1.211\mnt\vms Z:. |
| 7. | Cluster do Kubernetes | Ao aplicar uma atualização em seu dispositivo que esteja executando um cluster Kubernetes, as máquinas virtuais Kubernetes serão reiniciadas e reinicializadas. Nesse caso, apenas os pods implantados com réplicas especificadas são restaurados automaticamente após uma atualização. | Se você tiver criado pods individuais fora de um controlador de replicação sem especificar um conjunto de réplicas, esses pods não serão restaurados automaticamente após a atualização do dispositivo. Você deve restaurar esses pods. Um conjunto de réplicas substitui pods que são excluídos ou encerrados por qualquer motivo, como falha de nó ou atualização de nó com interrupções. Por esse motivo, recomendamos que você use um conjunto de réplicas, mesmo que seu aplicativo exija apenas um único pod. |
| 8. | Cluster do Kubernetes | O Kubernetes no Azure Stack Edge Pro é suportado apenas com o Helm v3 ou posterior. Para obter mais informações, vá para Perguntas frequentes: Remoção de Tiller. | |
| 9. | Kubernetes | A porta 31000 está reservada para o Painel do Kubernetes. A porta 31001 está reservada para o registro de contêiner de Borda. Da mesma forma, na configuração padrão, os endereços IP 172.28.0.1 e 172.28.0.10 são reservados para o serviço Kubernetes e o serviço Core DNS, respectivamente. | Não use IPs reservados. |
| 10. | Kubernetes | Atualmente, o Kubernetes não permite serviços LoadBalancer multiprotocolo. Por exemplo, um serviço DNS que teria que escutar em TCP e UDP. | Para contornar essa limitação do Kubernetes com o MetalLB, dois serviços (um para TCP, um para UDP) podem ser criados no mesmo seletor de pod. Esses serviços usam a mesma chave de compartilhamento e spec.loadBalancerIP para compartilhar o mesmo endereço IP. Os IPs também podem ser compartilhados se você tiver mais serviços do que os endereços IP disponíveis. Para obter mais informações, consulte Compartilhamento de endereços IP. |
| 11. | Cluster do Kubernetes | Os módulos de mercado existentes do Azure IoT Edge podem exigir modificações para serem executados no IoT Edge no dispositivo Azure Stack Edge. | Para obter mais informações, consulte Executar módulos existentes do IoT Edge a partir de dispositivos FPGA do Azure Stack Edge Pro no dispositivo GPU do Azure Stack Edge Pro. |
| 12. | Kubernetes | Não há suporte para montagens de associação baseadas em arquivo com o Azure IoT Edge no Kubernetes no dispositivo Azure Stack Edge. | O IoT Edge usa uma camada de tradução para traduzir ContainerCreate opções para construções do Kubernetes. A criação Binds de mapas para hostpath diretórios e, portanto, montagens de associação baseadas em arquivo não pode ser vinculada a caminhos em contêineres do IoT Edge. Se possível, mapeie o diretório pai. |
| 13. | Kubernetes | Se você trouxer seus próprios certificados para o IoT Edge e adicionar esses certificados em seu dispositivo Azure Stack Edge depois que a computação for configurada no dispositivo, os novos certificados não serão coletados. | Para contornar esse problema, você deve carregar os certificados antes de configurar a computação no dispositivo. Se a computação já estiver configurada, conecte-se à interface do PowerShell do dispositivo e execute os comandos do IoT Edge. Reiniciar iotedged e edgehub pods. |
| 14. | Certificados | Em certos casos, o estado do certificado na interface do usuário local pode levar vários segundos para ser atualizado. | Os seguintes cenários na interface do usuário local podem ser afetados. - Coluna de status na página Certificados . - Mosaico Segurança na página Introdução. - Bloco Configuração na página Visão geral . |
| 15. | Certificados | Os alertas relacionados a certificados de cadeia de assinatura não são removidos do portal mesmo após o upload de novos certificados de cadeia de assinatura. | |
| 16. | Proxy Web | Não há suporte para proxy da Web baseado em autenticação NTLM. | |
| 17. | Internet Explorer | Se os recursos de segurança aprimorados estiverem habilitados, talvez você não consiga acessar as páginas locais da interface do usuário da Web. | Desative a segurança reforçada e reinicie o navegador. |
| 18. | Kubernetes | O Kubernetes não suporta ":" em nomes de variáveis de ambiente que são usados por aplicativos .NET. Isso também é necessário para que o módulo Event Grid IoT Edge funcione no dispositivo Azure Stack Edge e em outros aplicativos. Para obter mais informações, consulte ASP.NET documentação principal. | Substitua ":" por sublinhado duplo. Para obter mais informações, consulte Problema do Kubernetes |
| 19. | Azure Arc + cluster Kubernetes | Por padrão, quando os recursos yamls são excluídos do repositório Git, os recursos correspondentes não são excluídos do cluster Kubernetes. |
Para permitir a exclusão de recursos quando eles são excluídos do repositório git, defina --sync-garbage-collection em Arc OperatorParams. Para obter mais informações, consulte Excluir uma configuração. |
| 20. | NFS | Os aplicativos que usam montagens de compartilhamento NFS em seu dispositivo para gravar dados devem usar a gravação exclusiva. Isso garante que as gravações sejam gravadas no disco. | |
| 21. | Configuração de computação | A configuração de computação falha em configurações de rede em que gateways, switches ou roteadores respondem a solicitações ARP (Address Resolution Protocol) para sistemas que não existem na rede. | |
| 22. | Computação e Kubernetes | Se o Kubernetes for configurado primeiro no seu dispositivo, ele reivindicará todas as GPUs disponíveis. Portanto, não é possível criar VMs do Azure Resource Manager usando GPUs depois de configurar o Kubernetes. | Se o seu dispositivo tiver 2 GPUs, você poderá criar uma VM que use a GPU e, em seguida, configurar o Kubernetes. Nesse caso, o Kubernetes usará a GPU restante disponível. |
| 23. | Extensão de VM de script personalizado | Há um problema conhecido nas VMs do Windows que foram criadas em uma versão anterior e o dispositivo foi atualizado para 2103. Se você adicionar uma extensão de script personalizada nessas VMs, o Agente Convidado de VM do Windows (somente Versão 2.7.41491.901) ficará preso na atualização, fazendo com que a implantação da extensão atinja o tempo limite. |
Para contornar esse problema: 1. Conecte-se à VM do Windows usando o protocolo RDP (Remote Desktop Protocol). 2. Certifique-se de que o waappagent.exe está em execução na máquina: Get-Process WaAppAgent. 3. Se o waappagent.exe não estiver em execução, reinicie o rdagent serviço: Get-Service RdAgent | Restart-Service. Aguarde 5 minutos.4. Enquanto o waappagent.exe está em execução, mate o WindowsAzureGuest.exe processo. 5. Depois de matar o processo, o processo começa a ser executado novamente com a versão mais recente. 6. Verifique se a versão do Windows VM Guest Agent é 2.7.41491.971 usando este comando: Get-Process WindowsAzureGuestAgent | fl ProductVersion.7. Configure a extensão de script personalizada na VM do Windows. |
| 24. | Serviço Multiprocesso (MPS) | Quando o software do dispositivo e o cluster Kubernetes são atualizados, a configuração MPS não é mantida para as cargas de trabalho. | Reative o MPS e reimplante as cargas de trabalho que estavam usando o MPS. |
| 25. | Wi-Fi | O Wi-Fi não funciona no Azure Stack Edge Pro 2 nesta versão. | |
| 26. | Azure IoT Edge | A solução gerenciada do Azure IoT Edge no Azure Stack Edge está sendo executada em um tempo de execução mais antigo e obsoleto do IoT Edge que está no fim da vida útil. Para obter mais informações, consulte IoT Edge v1.1 EoL: O que isso significa para mim?. Embora a solução não pare de funcionar após o fim da vida útil, não há planos para atualizá-la. | Para executar a versão mais recente do Azure IoT Edge LTSs com as atualizações e recursos mais recentes em seu Azure Stack Edge, recomendamos que você implante uma solução IoT Edge autogerenciada pelo cliente que seja executada em uma VM Linux. Para obter mais informações, consulte Mover cargas de trabalho do IoT Edge gerenciado no Azure Stack Edge para uma solução IoT Edge em uma VM Linux. |
| 27. | AKS no Azure Stack Edge | Nesta versão, você não pode modificar as redes virtuais depois que o cluster AKS é implantado no cluster do Azure Stack Edge. | Para modificar a rede virtual, tem de eliminar o cluster AKS, modificar redes virtuais e, em seguida, recriar o cluster AKS no Azure Stack Edge. |
| 28. | Atualização do AKS | A atualização do Kubernetes do AKS pode falhar se uma das VMs do AKS não estiver em execução. Esse problema pode ser visto no cluster de dois nós. | Se a atualização do AKS tiver falhado, conecte-se à interface do PowerShell do dispositivo. Verifique o estado das VMs do Kubernetes executando Get-VM o cmdlet. Se a VM estiver desativada, execute o Start-VM cmdlet para reiniciar a VM. Quando a VM do Kubernetes estiver em execução, reaplique a atualização. |
| 29. | Wi-Fi | A funcionalidade Wi-Fi do Azure Stack Edge Mini R foi preterida. |