Na plataforma HPC Shelf, pressupõe-se que a implementação de componentes de computação, que implementam algoritmos de computação paralela, está intimamente relacionada à plataforma de computação paralela alvo aonde esses componentes irão ser executados. Por esse motivo, a seleção de componentes se dá em torno de componentes sistema, definidos pelos pares formados por componentes de computação e a plataforma virtual alvo sobre a qual executará. Ao associar um componente de computação à sua plataforma de execução, novas possibilidades de suposições surgem no contexto de implementação para guiar o processo de seleção de componentes, motivadas a seguir.
Considere, por exemplo, um componente capaz de explorar o desempenho de um número arbitrário de nós de processamento. Sendo o especialista um usuário proprietário de uma conta com grande capacidade de recursos para execução, se considerada uma política arbitrária de uso de recursos da nuvem, ele pode solicitar a execução de um componente de maneira a influenciar o algoritmo de resolução para escolher uma plataforma virtual com a quantidade máxima de nós de processamento possível, o que, de acordo com o senso comum, seria uma garantia de que a execução da tarefa seria realizada de maneira mais rápida, em comparação com o cenário onde uma quantidade menor de nós de processamento fosse empregada. Desprezando- se suposições acerca dos limites de escalabilidade inerentes aos algoritmos paralelos, essa ideia estaria correta. Porém, sistemas de computação paralela, representados na HPC Shelf pelos componentes sistema, possuem limitações teóricas de escalabilidade do paralelismo, que fazem com que os algoritmos sofram perdas de desempenho devido a sobrecargas inerentes ao uso
de mais recursos de processamento na execução paralela (GRAMA, 2003). No caso de uma plataforma construída com o recurso de virtualização, também pode-se inserir os custos de inicialização das máquinas virtuais (SHI et al., 2011). Além disso, o especialista pode desejar não utilizar todos seus recursos nesta execução.
Para lidar com a análise da escalabilidade de sistemas de computação paralela, existem diversas técnicas de modelagem analítica para esses sistemas. Dentre essas técnicas, uma das mais conhecidas é a análise da função de isoeficiência, a qual permite calcular o número de nós de processamentos que devem ser usados para um certo tamanho de problema a fim de garantir um certo valor pré-estabelecido para a métrica de eficiência (GRAMA, 2003). A função de isoeficiência é determinada com o conhecimento de uma outra função que define a sobrecarga da execução paralela, necessária para calcular o tempo de execução da implementação de um algoritmo paralelo para uma determinado tamanho de entrada e número de nós de processamento.
A fim de otimizar o uso de recursos de computação na HPC Shelf, o Alite distingue parâmetros de contexto de componentes abstratos em quatro tipos:
• aplicação, referente a suposições da aplicação hospedeira em relação ao componente; • plataforma, referente a suposições da aplicação, ou do próprio componente, em relação
às características arquiteturais da plataforma virtual aonde o componente deverá ser instanciado e executar;
• qualidade, referente a suposições da aplicação acerca de aspectos do desempenho do componente, que podem incluir, por exemplo, métricas de aferição do seu desempenho computacional (tempo de execução, aceleração, eficiência, etc) e eficiência energética; • custo, referente a suposições da aplicação acerca do custo, em termos monetários, da
instanciação e execução de cada componente.
Parâmetros de aplicação e de plataforma já foram tratados nesta seção, de maneira uniforme. Já os parâmetros de qualidade e custo são uma extensão proposta pelo Alite a fim de atender a requisitos de políticas de uso de recursos computacionais na HPC Shelf, tanto globais quanto de aplicações em particular.
Conhecidas as propriedades da aplicação e da plataforma virtual que representam o ambiente de execução do componente, tais como o tamanho de problema e o número de unidades de processamento disponíveis, expressos em argumentos para parâmetros de contexto de aplicação e de plataforma, funções obtidas pela modelagem analítica podem então ser utilizadas para cálculo de argumentos para parâmetros de qualidade do sistema de computação paralela,
tais como eficiência energética, tempo de execução, aceleração, etc, a partir dos quais podem ser inferidos os argumentos para parâmetros de custo, que estabelecem os custos de utilização dos componentes, especialmente plataformas virtuais.
Na situação em que desenvolvedores de componentes de computação não forneçam valores para os parâmetros de qualidade padrão da plataforma, tampouco uma função de como devem ser calculados, seu custo de execução é considerado desconhecido, uma vez que é impossível determinar que recursos da plataforma virtual com a qual comporá um componente sistema serão necessários para a execução. Na melhor das hipóteses, poderá fornecer uma estimativa conservadora sobre o custo, a qual, por consequência, torna menos provável a escolha desse componente pela estratégia de resolução de contratos perante a existência de outros componentes que forneçam parâmetros que determinem suas métricas de qualidade, embora o custo cobrado possa ser menor do que a expectativa estabelecida em contrato na execução real. Dessa forma, supõe-se que desenvolvedores de componentes na HPC Shelf sentiriam- se estimulados a determinar modelos analíticos para os parâmetros de qualidade dos seus componentes, buscando um ajuste fino dessas métricas para diminuição dos custos de seus componentes e evitando penalidades por má reputação na oferta de serviços com o objetivo de otimização de lucros.
Pode-se afirmar que os contratos contextuais definem parte da noção de Acordo de Nível de Serviço (SLA) da nuvem HPC Shelf. A outra parte refere-se à definição das violações e das penalidades aplicadas pela HPC Shelf em caso de não cumprimento do acordado, a qual é definida de maneira global para todo o ambiente da nuvem. Porém, para que os acordos sejam respeitados, algumas metas de desempenho e disponibilidade devem ser definidas, de modo que cada meta descreve um Objetivo de Nível de Serviço (SLO3) (STURM et al., 2000). Parâmetros de qualidade e custo, uma vez que modelam métricas de qualidade e de custo, representam a noção de SLOs.
Como a HPC Shelf é uma nuvem de componentes que representam recursos de HPC para aplicações, são exemplos de SLOs: o desempenho medido em termos de tempo de execução; a quantidade de computação a ser realizada pelo componente, medido por número de operações de ponto-flutuante e aritmética inteira; e a movimentação entre hierarquias de memória. Outros parâmetros de qualidade podem também ser considerados relevantes, como parâmetros de disponibilidade, comumente utilizados em nuvens computacionais voltadas para 3 Service Level Objective.
Figura 17 – Fluxo do Cálculo de Parâmetros de Componentes
Fonte: Próprio Autor
aplicações comerciais.
Os parâmetros de custo, informados tanto por componentes de computação quanto por componentes da espécie plataforma, representam métricas de custo de execução do compo- nente e uso da plataforma, incluindo custos monetário e energético.
Seja hD, Pi um par que representa um componente sistema, onde D representa um componente de computação e P representa uma plataforma virtual que atende aos requisitos do contrato contextual do componente plataforma do qual D depende para executar. A Figura 17 sintetiza o fluxo de valoração dos parâmetros de SLO (qualidade e custo de serviço) a partir dos parâmetros de aplicação e plataforma. De fato, é preciso definir os argumentos e parâmetros de contexto do componente sistema hD, Pi a partir dos argumentos dos parâmetros de contexto de De P, vistos isoladamente.
Dpossui argumentos pré-definidos para os parâmetros de aplicação e argumentos para os parâmetros de plataforma que definem as suposições sobre a arquitetura da plataforma para a qual foi desenvolvida a fim de explorar melhor o desempenho potencial. Por sua vez, P possui argumentos para os parâmetros de plataforma que definem as suas características arquiteturais relevantes. Uma vez que a estratégia de resolução de contratos, na fase de seleção, casou D e P em um componente sistema, os argumentos dos parâmetros de plataforma de P são compatíveis com os argumentos dos parâmetros de plataforma de D. Nesse caso, para o componente sistema como um todo, prevalece os argumentos dos parâmetros de plataforma de P, que são mais específicos e, portanto, substituições seguras para os argumentos dos parâmetros de plataforma de D.
A partir dos argumentos dos parâmetros de aplicação e plataforma do componente sistema, respectivamente provenientes de D e P, os parâmetros de qualidade, definidos por D, podem se tornar conhecidos, sejam pré-fixados ou calculados por meio de funções derivadas
de modelagem analítica sobre os valores dos argumento dos parâmetros de plataforma (ex: número de nós de processamento, núcleos de processamento por nó, presença e característica do acelerador, etc) e da aplicação (ex: tamanho do problema, caracterísitca da entrada, etc).
Por sua vez, os argumentos dos parâmetros de custo da plataforma P e do componente Dpodem ser calculados a partir dos argumentos dos parâmetros de qualidade do componente sistema, derivados de D, usando funções que levam em conta aspectos econômicos. A partir desses custos, a aplicação pode calcular, com auxílio de serviço de contabilização da nuvem, qual o valor monetário devido pelo especialista e o que deverá ser repassado para o provedor da aplicação (montador), desenvolvedor do componente D e mantenedor da plataforma P.
Os parâmetros de plataformas e SLOs, ou seja, os parâmetros de qualidade e de custo, são pré-definidos pela nuvem HPC Shelf. Porém, uma vez que o arcabouço é genérico, esse conjunto de parâmetros pode evoluir com o tempo, em novas versões da HPC Shelf, mantendo compatibilidade vertical e horizontal. O gerenciamento de nível de serviço se dá pela comparação entre as metas de qualidade, definidas nos contratos contextuais, e os argumentos calculados para os respectivos parâmetros pelos componentes.
Parâmetros de contexto de aplicação, plataforma, qualidade e custo não são os únicos introduzidos por Alite. Na Seção 4.3.2, serão ainda introduzidos os parâmetros de ranqueamento, cuja finalidade é especificar políticas de alocações de recursos alternativas suportadas pela plataforma (e.g. HPC Shelf), que podem ser escolhidas dinamicamente pelas aplicações ao executar sistemas de computação paralela. Ainda nessa seção, especificamente na Seção 4.3.2.2, a noção de subtipos entre parâmetros de qualidade e de custo é explicada de maneira mais precisa, em termos de valores de parâmetros de ranqueamento.