Oportunidades para reduzir os custos WLC 25/nov/15. Fernando Gandara

Transcrição

1 Oportunidades para reduzir os custos WLC 25/nov/15 Fernando Gandara

2 Agenda Eficiência Operacional Capacity Planning WLC & Mobile Workload Pricing Situação 1 Desvios de Consumo Situação 2 Mais Desvios de Consumo Situação 3 Sistemas Inesperados Situação 4 Usando ziip Situação 5 Mobile Workload Pricing (MWP) Conclusões

3 Eficiência Operacional (%) Disponibilidade x (%) Eficiência de Performance x (%) Taxa de Qualidade É a minimização de problemas e maximização das capacidades de recursos a fim de oferecer produtos e serviços de qualidade aos clientes. Ao melhorar a eficiência operacional, obtêm-se um impacto direto sobre as margens de lucro da companhia. A entrega dos sistemas para a área de negócio em menor tempo (TIME-TO-MARKET) é um fator relevante na eficiência operacional e significa reduzir tempo e custos de chegada ou reposição do produto, como forma de manter vantagem competitiva perante os concorrentes.

4 Capacity Planning O desafio de gerenciar um ambiente de alta complexidade passa pelo dimensionamento de infraestrutura de TI, seja para evitar surpresas, seja para manter TI alinhada às expectativas de demandas do negócio (crescimento natural do negócio ou demandas pontuais que exijam mais dos sistemas da organização), bem como se manter competitivo em um cenário de custos otimizados e tem por objetivo: Obter uma visão geral sobre a capacidade existente na infraestrutura e capacidade sistêmica; Ter possibilidade de planejar a capacidade antecipadamente; Estimar o impacto de novas aplicações ou modificações de funcionalidade no ambiente; Obter economia de custos; Alcançar melhores serviços em harmonia com os requisitos de negócio.

5 WLC & Mobile Workload Pricing Workload License Charges (WLC) é uma métrica de cobrança mensal da IBM, desenhada para suportar os requerimentos de negócio sob demanda. WLC faz parte do Monthly License Charge (MLC), que é um tipo de cobrança que inclui o direito de uso do produto assim como o suporte de produto da IBM durante esse periodo. Outras formas de licenciamento incluem: Advanced Workload License Charges (AWLC), Advanced Entry Workload License Charges (AEWLC), Entry Workload License Charges (EWLC), Midrange Workload License Charges (MWLC), System z New Application License Charges (znalc), etc. O WLC permite o crescimento de capacidade de hardware sem o aumento da cobrança de software, o pagamento de softwares chave como: DB2, CICS, IMS, WebSphere MQ e z/os com granularidade a nível de LPAR e o gerenciamento do custo de software através do gerenciamento da utilização do workload. O Mobile Workload Pricing (MWP) para z/os melhora o custo de crescimento para transações mobile em ambientes como: CICS, IMS, DB2, WAS e MQ, mas requer controle e trilha nas respectivas transações mobile.

6 Situação 1 Desvios de Consumo

7 A primeira coisa a controlar é em que dia ocorreu o pico mensal MSU. Espera-se que isso aconteça em um dia de trabalho e, provavelmente, em um dia de crítico de negócios (por exemplo, no final ou no início do mês). Um relatório simples como da figura ao lado pode permitir uma verificação muito fácil e rápida. Máquina é uma com MSUs. O Relatório refere-se a fevereiro O pico médio mensal de 4 horas de é de MSUs Foi o que aconteceu no domingo. Observe a grande diferença com o segundo valor de pico (955 MSUs, diferença de 354 MSUs) Situação 1 Desvios de Consumo

8 Situação 1 Desvios de Consumo Para este cliente, sábado e domingo não são dias úteis para que um alto valor como o ocorrido no domingo e deve ser considerado anormal. Neste caso, foi causado por um atividade pesada de recuperação que ocorreu por muito tempo para corrigir um problema de corrupção de dados depois da migração para novos processadores de armazenamento que aconteceu no dia anterior. Os clientes têm a responsabilidade primária para a prevenção de loops não controlados, erros do operador ou picos de utilização indesejados. No entanto, a IBM entende que, ocasionalmente, situações que não poderiam ser evitadas (especialmente relacionadas com situações de recuperação de desastres) podem causar custos excepcionais de utilização. Nessas situações, a IBM não espera que os clientes venham a pagar o aumento da respectiva utilização associada com a situação incomum.

9 Situação 1 Desvios de Consumo Deve-se usar o bom senso para determinar se uma situação incomum ocorreu. A IBM não publica uma lista de situações inusitadas, porque, pela sua natureza, eles serão imprevisíveis. Retirado do manual "Using the Sub-Capacity Reporting Tool". As regras para o WLC preveem a possibilidade de gerir "situações incomuns", excluindo algumas horas ou dias do cálculo da fatura. Esta é a razão do porque se interceptar e documentar situações assim se torna muito importante. Fale com a IBM...

10 Situação 2 Mais Desvios de Consumo

11 Muitas vezes, o pico mensal ocorre em um dia críticos de negócios. Neste caso, o passo seguinte na verificação do WLC deve ser feita para avaliar-se em que hora(s) do dia o pico ocorreu. O que desencadeou a atenção do cliente no relatório ao lado é a diferença entre o primeiro dia de pico e todos os demais dias. A Maquina é uma com MSUs. O Relatório refere-se a Dezembro de O pico médio mensal de 4 horas é de MSUs. Foi o que aconteceu em uma sexta-feira. A diferença com o segundo valor de pico é de 103 MSUs. Situação 2 Mais Desvios de Consumo DATE DAY TYPE MODEL MSU USED 19/12/2014 Fri /12/2014 Wed /12/2014 Thu /12/2014 Mon /12/2014 Tue /12/2014 Mon /12/2014 Tue /12/2014 Thu /12/2014 Tue /12/2014 Wed /12/2014 Wed /12/2014 Tue /12/2014 Mon /12/2014 Fri /12/2014 Wed /12/2014 Fri /01/2015 Thu /12/2014 Sat /12/2014 Sat /12/2014 Thu /12/2014 Sat /12/2014 Mon /12/2014 Sun /12/2014 Sun

12 Situação 2 Mais Desvios de Consumo Ao analisar o dia de pico ao nível da hora ocorrida, o cliente percebeu que algo estranho havia ocorrido. Eles normalmente têm o pico de workload na parte da manhã assim eles esperavam ter o pico de MSU utilizado na média móvel de 4 horas logo após o meio-dia. Na verdade, um valor alto (907) foi relatado às 14hs (14:00:00-14:59:59), mas no final da tarde a utilização em MSU subiu para um valor muito mais elevado (1.017). Olhando para as contribuições dos os diferentes sistemas, parecia claro que o pico foi devido a algo que roda dentro do sistema SYS2. O cliente pediu à equipe técnica uma análise mais profunda. SYSTEM SYS SYS SYS SYS TOTAL

13 Situação 2 Mais Desvios de Consumo O pico do fim da tarde foi causado por um usuário TSO em loop. Pode-se ver no relatório abaixo o TSO001 usado sobre todas as MSUs de um processador continuamente por cerca de 5 horas. WKL ADDRESS SPACE SRVCLASS MEAN TSO TSO001 TSO JOB BATCH001 BATCHHI 31 4,8 56,3 JOB BATCH002 BATCHHI 25 27,3 49,2 8,6 14,5 JOB BATCH005 BATCHHI 24 31,3 38,8 0,5 JOB BATCH006 BATCHHI 23 29,9 38,8 0,5 JOB BATCH008 BATCHHI 22 8,3 18,8 28,2 49, ,1 22,7 1,3 DB2 DB2DIST DDFDB ,5 22,7 33,4 52, ,7 6,6 5,6 3,3 8,7 3,8 1,2

14 Situação 2 Mais Desvios de Consumo Os clientes têm a responsabilidade primária para a prevenção de loops não controlados, erros do operador ou picos de utilização indesejados. No entanto, a IBM entende que, ocasionalmente, situações que não poderiam ser evitadas (especialmente relacionadas com situações de recuperação de desastres) podem causar custos excepcionais de utilização. Nessas situações, a IBM não espera que os clientes venham a pagar o aumento da respectiva utilização associada com a situação incomum. Deve-se usar o bom senso para determinar se uma situação incomum ocorreu. A IBM não publica uma lista de situações inusitadas, porque, pela sua natureza, eles serão imprevisíveis. Retirado do manual "Using the Sub-Capacity Reporting Tool". As regras para o WLC preveem a possibilidade de gerir "situações incomuns", excluindo algumas horas ou dias do cálculo da fatura. Esta é a razão do porque se interceptar e documentar situações assim se torna muito importante. Fale com a IBM...

15 Situação 3 Sistemas Inesperados

16 Situação 3 Sistemas Inesperados Cada site executa sistemas dedicados a diferentes workloads, atividades como produção, desenvolvimento de aplicativos, teste de aplicação, teste do sistema, etc. Em uma situação normal espera-se que a conta mensal WLC esteja relacionada com a quantidade de MSUs usados por sistemas de produção. Um relatório que mostra a contribuição de cada sistema para o pico mensal MSU pode ser muito útil, como no relatório ao lado. DATE TYPE MODEL MSU PROD TST1 TST2 ZNET TOTAL A Maquina é uma com 1,139 MSUs O Relatório refere-se a 1 ano (Nov 2010-Out 2011) O pico médio mensal de 4 horas é de MSUs em Out O consumo pelo sistema ZNET dobrou nesse mes.

17 O workload ZNet é utilizado para ser muito estável. Algo aconteceu em 24 de outubro, uma segunda-feira. A primeira idéia era verificar as atividades de manutenção realizadas no fim de semana. Uma análise mais detalhada do workload ZNet mostrou um aumento de CPU correspondente do session manager address space. A nova versão do gerenciador de sessões provocou esse grande aumento (cerca de 40 MSUs). Neste caso, a maior parte destes MSUs foram recuperados graças a algumas PTFs. Situação 3 Sistemas Inesperados Ser capaz de medir e relatar esse problema deram ao cliente a possibilidade de discutir as contas mensais de outubro e novembro com a IBM, a fim de reduzi-los. DATE DAY MSU SYSA TST1 TST2 ZNET TOT 16/10/2011 Sun /10/2011 Mon /10/2011 Tue /10/2011 Wed /10/2011 Thu /10/2011 Fri /10/2011 Sat /10/2011 Sun /10/2011 Mon /10/2011 Tue /10/2011 Wed /10/2011 Thu /10/2011 Fri /10/2011 Sat /10/2011 Sun /10/2011 Mon /11/2011 Tue

18 Situação 4 Usando ziip

19 Situação 4 Usando ziip Transferindo-se o máximo de workloads possíveis para ziip é um pontochave na estratégia de qualquer cliente que realmente queira reduzir os custos de hardware e de software. Devido à complexidade dos sistemas atuais, não é raro encontrar clientes que têm workloads elegíveis para ziip e que estão sendo executados em CPUs padrão aumentando assim a fatura mensal de software. As razões mais comuns para este resultado indesejado são: PRSM e parâmetros de sistema errados. Falta de PTFs. Loops. ziip insuficiente face a estimativas erradas no processo de planejamento de capacidade.

20 Situação 4 Usando ziip A coluna CURR mostra os MSUs utilizados na média móvel de 4 horas. NO IIPCP é uma estimativa do que o valor CURR seria se houvesse ziip suficiente. IIPCP foi sempre substancialmente inferior a CURR. Em outubro 2014 pico hora a diferença é de 111 MSUs. DATE CURR NO IIPCP

21 Situação 4 Usando ziip

22 Situação 4 Usando ziip IIPCP foi sempre substancialmente inferior a CURR. Considerando-se os maiores valores de CURR e NO IIPCP em outubro de 2014, mesmo ocorrendo em dias diferentes, a diferença entre CURR e NO IIPCP tinha 75 MSUs. Isto significa que uma quantidade substancial de dinheiro poderiam ter sido economizada se mais ziips estivessem disponíveis. Estes números são estimados com base no registro 72 do SMF (SMF 30 também pode ser usado) e são necessários os seguintes passos: Transformar CPU e SRB service units, providos nos registros 72 do SMF, em MSUs. Incrementar o uso da CPU contabilizado para os períodos do WLM service class de modo a contabilizar para a CPU não capturada. Somar os MSUs separando apenas a CPU que funciona somente para workloads elegíveis para zaap e ziip e que estão em execução na CPU convencional. Calcule a média móvel de 4 horas de MSU baseado na elegibilidade zaap e ziip.

23 Situação 5 Mobile Workload Pricing (MWP)

24 Situação 5 Mobile Workload Pricing (MWP) Em 06 maio de 2014 a IBM anunciou Mobile Workload Pricing for z/os (MWP). Este novo modelo de preços é projetado "para atenuar o impacto dos workloads em aplicações mobile para cobranças de sub-capacity license e fornecer um software mais competitivo em termos de custos". O Mobile Workload Pricing (MWP) para z/os melhora o custo de crescimento para transações mobile em ambientes como CICS, IMS, DB2, WAS e MQ, mas requer controle e trilha nas respectivas transações mobile. Pre-requisitos chave para habilitar MWP inclui: Ter sistemas z/os V1 ou z/os V2 Executar em servidores z13, zec12, zbc12, z196 ou z114 que estão sob subcapacity pricing sobr AWLC ou AEWLC Rodar um ou mais dos Mobile Workload Pricing Defining Programs (CICS, IMS, DB2, WebSphere e Websphere MQ versões mais recentes) Mobile Workload Reporting Tool (MWRT) deve ser usado no lugar do SCRT, para submeter os relatórios mensais WLC monthly à IBM

25 Source: IBM Situação 5 Mobile Workload Pricing (MWP)

26 Situação 5 Mobile Workload Pricing (MWP) MWRT exclui 60% do workload móvel, intervalo por intervalo, em cada LPAR em que o workload móvel é executado. Workload não-móvel não será alterado. Os clientes irão obter uma redução de custos quando os workloads móveis contribuem para o pico mensal de MSUs. Workloads móveis fora do pico não afetarão os MSUs utilizados para o faturamento. Exemplo: O pico mensal da média móvel de 4 horas é de 980 MSUs e, nesse pico, a média móvel de 4 horas de workload móvel reportado é de 300 MSUs. Neste caso 180 MSUs (60% de 300) vai ser descontado reduzir a carga a 800 MSUs. Se este valor permanecer comoo pico mensal, será cobrado 800 MSU. Se, após o desconto, o pico estiver em uma hora diferente do mês, o pico MSU recalculado será cobrado.

27 Situação 5 Mobile Workload Pricing (MWP) 1200 Chargeable MSU reduction due to Mobile Workloads 4 H R o l l i n g A V G 400 M S U MSU after Mobile discount MSU

28 Situação 5 Mobile Workload Pricing (MWP) IBM definiu o formato para o arquivo CSV para que o cliente forneça a entrada de transações móveis para o MWRT. Deve haver um arquivo CSV separado para cada família de produtos, ou seja, CICS, WebSphere MQ, IMS, WebSphere ou DB2. Os clientes têm de preparar todos esses arquivos CSV.

29 Situação 5 Mobile Workload Pricing (MWP) A primeira linha é a linha de produto contendo a identificação do produto (ou ids) para todas as versões de uma família de produtos que o cliente esteja usando para o processamento de workload móvel. Coluna um da linha do Cabeçalho é o cabeçalho data ou seja: Data indicando que todos os tempos são locais e no formato ISO-8601 DateUTC indica que todos os tempos estão no formato UTC na ISO-8601 As colunas subsequentes da linha do Cabeçalho precisam conter os nomes das LPARs: Apenas o nome da LPAR (exemplo SYSF ), ou type-serial:lpar name (exemplo F4D7:SYSF ) Cada célula na linha de dados da transação mobile precisa ter os segundos de CPU naquele horário naquela LPAR como um numero ponto flutuante.

30 Conclusões Apresentamos 4 importantes situações que podem ser usadas para manter os custos sob licenciamento WLC. Foram apresentados também relatórios WLC concebidos e que permitem que se executem essas verificações de forma rápida e eficiente. Ser capaz de identificar claramente as questões tornam possível não apenas reduzir os custos do próximo mês, mas, dependendo do assunto, pode-se até mesmo reduzir a conta do mês atual. As novas tecnologias de hardware e software devem ser avaliadas para verificar se elas podem também fornecer economias e para esses casos tais relatórios também se fazem necessários. O mesmo se aplica para as novas opções de licenciamento de software (exemplo MWP).

31 Fernando Gandara (11)