Personalização da frota

Tipo de frota

Ao criar uma frota, os clientes devem escolher um tipo. Cada tipo de frota oferece benefícios diferentes para a experiência do usuário, custos e despesas gerais de manutenção. Independentemente do tipo de frota escolhido, cada opção é compatível com os tipos de plataforma Windows e Linux, bem como o Desktop View ou o Application View.

Os clientes já podem escolher entre os seguintes tipos de frota:

• Sempre ativa: esse tipo de frota fornece os usuários acesso instantâneo aos aplicativos. Você será cobrado por todas as instâncias em execução na frota, mesmo se nenhum usuário estiver fazendo streaming de aplicativos.

• Sob demanda: selecione esse tipo de frota para otimizar os custos de streaming. Com uma frota sob demanda, os usuários terão um horário de início de aproximadamente um a dois minutos para a sessão. No entanto, você só pagará as taxas da instância de streaming quando os usuários estiverem conectados e uma pequena taxa horária para cada instância da frota que não seja um aplicativo de streaming.

• Elástica: as frotas elásticas podem ser usadas para aplicativos que não exigem instalação e podem ser executados a partir de um disco rígido virtual (VHD). As frotas elásticas não dão suporte a imagens do AppStream 2.0, nem exigem políticas de escalabilidade. Você será cobrado apenas pela duração de uma sessão de streaming.

Tabela 2: tipos de frota do Amazon AppStream 2.0

Tipo de frota	Quando usar	Experiência do usuário	Modelo de definição de preços	Observações
Sempre ativo	Os usuários precisam de acesso instantâneo aos aplicativos quando iniciam uma sessão. Você não terá excesso significativo de capacidade em sua frota, talvez porque os padrões de uso sejam previsíveis e seja possível controlar os custos de modo confiável com políticas de escalabilidade.	Acesso instantâneo aos aplicativos	Você paga o preço total por cada instância disponível na frota (independentemente de ser usada para uma sessão).	Oferece suporte a políticas personalizadas de imagem e escalabilidade.
Sob demanda	Você deve manter um excesso significativo de capacidade em suas frotas. Você quer o ambiente mais econômico e não quer pagar o preço total pela capacidade não utilizada. Os usuários podem esperar de um a dois minutos para acessar os aplicativos depois de iniciar uma sessão. Você está usando tipos de instância maiores. O custo por hora de uma instância em execução é muito mais caro do que a taxa de instância interrompida.	Os usuários esperam de um a dois minutos para acessar os aplicativos depois de iniciar uma sessão.	Você paga o preço total somente pelas instâncias de streaming com uma sessão ativa e, em seguida, um pequeno custo por hora pelas instâncias ociosas.	Oferece suporte a políticas personalizadas de imagem e escalabilidade.
Elástica	O aplicativo e suas dependências têm menos de ~1,5 GB. Sempre um usuário inicia uma sessão em uma frota elástica, seu arquivo de disco rígido virtual (VHD) deve ser baixado do Amazon S3 para a sessão. Como resultado, arquivos de VHD maiores (ou seja, com mais de 1,5 GB) resultarão em uma experiência inadequada para o usuário final. O aplicativo é portátil. Ou seja, o aplicativo e todas as suas dependências podem ser colocados em um VHD e iniciados a partir do VHD. Não são necessárias instâncias de streaming unidas ao domínio (atualmente, a associação de domínios não está disponível com frotas elásticas). Você quer pagar somente pelas sessões ativas (ou seja, não pagar pela capacidade não utilizada em sua frota). Os usuários podem esperar 45 segundos ou mais para acessar os aplicativos depois de iniciar uma sessão. Você deseja que a AWS gerencie a escalabilidade (sem políticas de escalabilidade para gerenciar).	O usuário espera de 45 segundos a três minutos para acessar os aplicativos após iniciar a sessão (o tempo de espera depende do tamanho do disco rígido virtual).	Você será cobrado apenas pela duração de uma sessão de streaming. Como não existe o conceito de instâncias ociosas com frotas elásticas, você não incorre em cobranças por instâncias não utilizadas.	Não há suporte a imagens personalizadas (o cliente fornece aplicativos ao VHD) nem a políticas de escalabilidade. Atualmente, dá suporte para instâncias de stream.standard.small e stream.standard.medium. Caso seu caso de uso exija um tipo de instância diferente, entre em contato com a equipe da sua conta da AWS.

Casos de uso e requisitos do tipo de frota

Dimensionamento da frota

Capacidade mínima e ajuste da escala programado

Ao dimensionar sua frota do AppStream 2.0, há várias considerações que se traduzem diretamente na experiência do usuário e no custo. O valor inserido para Capacidade mínima garante que o número de instâncias do AppStream 2.0 raramente seja menor do que esse valor. Após o término de uma sessão do AppStream 2.0, se o total de instâncias for menor que o valor mínimo da capacidade, uma nova instância de frota será iniciada. Como sempre, é importante lembrar que uma instância do AppStream 2.0 é mapeada diretamente para uma sessão de usuário, influenciando diretamente o valor da capacidade mínima.

Inserir um valor para a capacidade mínima que esteja além da simultaneidade prevista resulta em aumento de custo, embora a experiência do usuário não seja afetada. Um valor muito baixo resulta em custos reduzidos, mas afeta a experiência do usuário quando o total de solicitações excede a capacidade disponível. Os administradores observarão erros de “Capacidade insuficiente” nesse tipo de situação. Por exemplo, esperar PendingCapacity se tornar AvailableCapacity é um uso ineficiente do tempo do usuário quando o número de conexões previstas no início do dia é um valor previsivelmente consistente.

Comece com uma capacidade mínima que acomode os horários típicos fora de pico e, em seguida, use a política de ajuste de escala programada para redefinir efetivamente a capacidade mínima antes do início do dia de trabalho. Não se esqueça de criar outra política de ajuste de escala programada para reverter a capacidade mínima para os horários fora do pico. Para obter mais informações sobre políticas de ajuste de escala e como implementá-las, consulte a seção Estratégias de ajuste de escala automático de frotas neste documento.

Capacidade máxima e cotas de serviço

A definição da capacidade máxima pode parecer um valor arbitrário, mas quando previsto e definido adequadamente, otimiza o consumo e o custo total dos recursos. Um valor inserido maior do que a cota de serviço da frota do AppStream 2.0 na Conta da AWS pode parecer válido, mas, quando eventos de ajuste de escala automático tentam escalar recursos até a capacidade máxima, eles não são iniciados, pois o valor máximo da capacidade excede a cota de serviço disponível. Garanta que uma solicitação de cota de serviço exista para a capacidade máxima desejada, garantindo as funções de ajuste de escala automático conforme previsto pela sua organização.

Outra consideração importante ao definir um valor máximo de capacidade é o custo. Para obter mais informações, consulte a seção Como otimizar custos com a escolha do tipo de frota deste documento.