Notícias e Eventos Blue Solutions

Atualizações sobre produtos, Informações Técnicas, Dicas para Ambientes de TI, Virtualização, NOC, Operações de TI, Serviços de Segurança, Serviços Gerenciados, Recuperação de Desastres, Continuidade de Negócios e notícias da Blue Solutions.

Qual provedor de Computação em Nuvem vai fazer chover primeiro? Office 364 ou AmazOff? Uma crítica sobre Computação em Nuvem

Nenhum comentário


Com todo o buzz de mercado sobre Computação em Nuvem, é comum que uma empresa queira fazer a movimentação de seus dados e aplicações para a nuvem.

Claro que a Computação em Nuvem tem seus benefícios reais, como escalabilidade e pagar sob demanda, é um modelo de negócio bem atrativo.

Mas do lado do datacenter, qual a complexidade para atender todos esses clientes? Dezenas de milhares de clientes significa milhares de servidores, milhares de portas nos switches, tecnologia de ponta (e menos base testada), ferramentas de automatização específicas (usada apenas pelos grandes provedores, com bugs que podem acontecer só com eles), enfim, um problema que acontecer no datacenter de grande porte, sempre vai ser mais complexo de resolver do que um simples reboot em um servidor local.

Sim, isso já aconteceu antes:


Se continuarmos buscando, vamos encontrar mais e mais casos de problemas nos principais datacenters e serviços de nuvem online.

Sua empresa pode ficar 1 dia sem e-mail porque o provedor de nuvem está com um problema sério? Ou porque estão sofrendo um ataque DDoS? E se sua empresa sofrer um ataque DDoS? Além de ficar sem Internet, fica sem acesso aos dados e aplicativos.

Sem duvidar da competência ou da capacidade de solução de problemas de cada um deles, será que toda a complexidade extra não adiciona uma camada extra de problemas que não teríamos se os servidores estivessem "em casa"?

Falando em complexidade extra, como os dados estão fora da empresa, a mesma fica obrigada a ter no mínimo 2 links de Internet com operadoras diferentes para acessar os dados, o que não precisaria se os dados estivessem na empresa... bom, redundância de Internet sempre é bom, mas poderiam ser 2 links de baixo custo e não 2 links profissionais com SLA e tudo mais.

E o que falar da segurança? Será que um funcionário desse datacenter não é corruptível a ponto de entregar os dados da sua empresa para seu concorrente? E as operadoras de interconexão? Você tem certeza que todas as conexões e dados estão criptografados? Já ouviu falar dos ataques de Man-In-The-Middle contra conexões SSLv2? Ataque de Heartbleed? E o ataque de Blue Pill?

E quando acontecer a falha? Você vai culpar quem? Será que a culpa não é sua por ter escolhido o datacenter errado? Mas qual o datacenter correto?

Os dados da sua empresa estão hospedados no seu país? E os backups, também estão no seu país? E a contingência deles? Será que os dados estando na nuvem não ficam mais suscetíveis a espionagem de agências e concorrentes mundo afora?

Será que o Datacenter escolhido está localizado em uma área sujeita a desastres naturais? E as linhas de comunicação que ligam o mesmo até sua empresa? E as linhas de energia nesse caminho? Mesmo que não seja uma interrupção total, mas uma degradação nos serviços pode custar horas de produtividade da equipe.

E os impostos? Você contratou um datacenter que é local, mas e a fatura? Um  grande provedor de nuvem, embora tenha infraestrutura no Brasil, tem efetuado as cobranças pela matriz nos EUA, com isso sua empresa fica responsável por recolher os impostos. E se não está recolhendo, está sonegando, sujeito a multa.

Por último, o que acontece se um provedor de nuvem entender que você não pagou a conta? O cartão de crédito foi cancelado e seu financeiro esqueceu de trocar no provedor, depois saiu de férias e ninguém está olhando os e-mails de aleta, em quanto tempo seu serviço será cancelado? E em quanto tempo será reestabelecido assim que efetuar o pagamento?

Enfim, embora a nuvem tenha suas vantagens, deve-se considerar os riscos, e ficar atento aos detalhes para que não se transforme numa tempestade e para que seus dados não vão embora com a chuva.


Sobre o autor
Fernando Ulisses dos Santos
Diretor de Tecnologia na Blue Solutions
Especialista em Segurança da Informação
Certificado VCP-DCV, VCAP-DT, VCP-DT

Nenhum comentário :

Postar um comentário

Você sabe onde você gasta seu Tempo?

Nenhum comentário
“Se você não pode medir, você não pode gerenciar” - Peter Drucker

Você trabalha com computador no seu emprego? Ou tem que fazer trabalhos de escola, faculdade no computador? Muitas vezes percebe que senta na frente do mesmo, fica ali horas trabalhando, e não fez nada do que planejou? Você sabe quanto tempo fica no WhatsApp no celular? Quanto tempo fica no Facebook no celular?

Bom, seu tempo não sumiu, ele foi para algum lugar, e nada como conhecer para onde foi o tempo para poder gerenciar melhor e decidir sobre o mesmo.

Eu também já passei por isso, e por um período eu fiz anotações manuais, usei planilhas e alguns softwares manuais, até que descobri o Rescue Time, é um software para medição de tempo em computadores.

Ele mede quantos minutos você gasta em cada aplicativo e depois exibe em forma de um Dashboard:



Claro, ele contabiliza apenas o aplicativo ou site que está em foco no computador (o qual você está realmente trabalhando), e classifica automaticamente os aplicativos e sites mais comuns entre produtivo ou distração.

Olhando para o dashboard você pode descobrir quanto tempo gasta efetivamente em cada aplicativo (quanto tempo dá somando todas aquelas olhadinhas no WhatsApp de vez em quando?)

Você pode configurar Metas, por exemplo, gastar apenas 1 hora por dia no software de E-mail, e ele vai te avisar quando estiver quase batendo a meta.

O que você está esperando? Faça já o Download, é GRÁTIS!

Fazer Download Grátis do RescueTime


Sobre o autor
Fernando Ulisses dos Santos
Diretor de Tecnologia na Blue Solutions
Especialista em Segurança da Informação
Certificado VCP-DCV, VCAP-DT, VCP-DT

Nenhum comentário :

Postar um comentário

Business Monitor: Indicadores de Negócio e Gestão a Vista

Nenhum comentário

Nenhum comentário :

Postar um comentário

6 Indicadores para TI que fazem a diferença na sua Gestão

Nenhum comentário
Um dos maiores desafios na hora de criar indicadores de negócio para a área de TI é fugir do óbvio.

Muitos gestores acabam implementando apenas os indicadores simples, como quantidade de chamados resolvidos por mês, quantidade de chamados por prioridade total, ou ainda a quantidade de chamados resolvidos por técnico ou por serviço total, esses indicadores são úteis sim, mas a utilidade deles é limitada normalmente apenas para observar o que já aconteceu e planejar o futuro, e não para resolver problemas imediatos.

Ao invés de gerar apenas os indicadores históricos, podemos extrapolar o uso de sistemas em tempo real para extrair a situação imediata da TI, e criar indicadores que permitam tomar uma ação sobre o que está acontecendo, agilizando a solução de problemas e aumentando a satisfação dos usuários.

Seguem algumas sugestões de indicadores que podem fazer a diferença na sua gestão:

1. Quantidade de chamados abertos agora


Esse indicador pode ser exibido com um gráfico de Gauge simples, como no exemplo. Aqui podemos observar que a meta ideal é ter menos de 20 chamados abertos, e o ponto crítico é ter mais de 40 chamados abertos.


Atingir alguns valores pode significar o gatilho para disparar algumas ações, por exemplo, se tiver menos de 10 chamados abertos, o gestor pode colocar algum técnico de folga para compensar horas, se atingir mais de 45 chamados abertos, pode tirar algum técnico de férias para atender melhor os clientes.


Claro que o número ideal de chamados varia de organização para organização. Para chegar no número ideal é necessário um trabalho de observação, verificar a quantidade média de chamados abertos durante um período (por exemplo: 30 dias) e o grau de satisfação dos usuários (trataremos disso a seguir).

Podem-se estabelecer pequenas metas de melhoria, como diminuir a fila média em 5 chamados abertos no prazo de 1 mês e usar isso como incentivo para os colaboradores.

Também vale diferenciar o status do chamado, se for novo ou aberto e estiver dependendo da ação de um técnico, pode ficar exibido em um gráfico separado dos chamados que estão pendente da resposta do usuário ou da ação de outro setor, por exemplo, se for um chamado que dependa da compra de teclados para substituir.

2. Quantidade de chamados abertos por técnico


Na mesma linha de raciocínio do gráfico anterior, saber quantos chamados cada técnico está tratando permite tomar algumas ações corretivas imediatas.

Deve-se esperar que 2 técnicos com o mesmo perfil e o mesmo cargo tenham uma quantidade quase igual de chamados para tratar, ao mesmo tempo que técnicos de nível 1 e nível 2 tenham números diferentes. No caso de dois técnicos estarem desbalanceados, o gestor deve intervir para descobrir porque um tem mais chamado que outro e redistribuir os chamados se for o caso. Com o tempo os próprios técnicos podem fazer essa correções.

Também quanto ao nível, o técnico de nível 1 tende a resolver mais chamados (e consequentemente ter uma fila maior) que o técnico de nível 2; em compensação, os chamados no nível 2 são mais complexos e requerem mais tempo, isso poderá ser observado nos indicadores, e pode indicar a sobrecarga de algum nível ou especialista.

3. Chamados abertos por usuário ou cliente

Esse indicador mostra quantos chamados tem aberto para cada usuário interno, e a importância dele é que mostra a percepção do serviço prestado.

Um usuário que tem muitos chamados abertos pode entender que a TI não resolve seus problemas, ficar insatisfeito e ser fonte de reclamações e atritos dentro da empresa.

Resolver os chamados mais simples desse usuário pode mudar toda a percepção do mesmo, fica mais fácil dele entender que o chamado que ainda não foi resolvido é realmente complicado e requer mais tempo, enquanto percebe que a TI está fazendo o trabalho correto com os recursos disponíveis.

O indicador também pode demonstrar com cores diferentes prioridades entre usuários, por exemplo, um Diretor ou Gerente pode ter prioridade de atendimento frente a outro colaborador, tendo em vista que seu trabalho pode impactar mais a empresa.

4. Classificação dos Chamados nos últimos 30/60/90 dias


Entender se a TI trabalha mais apagando incêndio, atendendo solicitações de usuários, em atividades preventivas ou em projetos é um indicador óbvio.

Mas comparar o mesmo em períodos diferentes pode indicar desvio de função ou queda na qualidade dos serviços.

Por exemplo, pode-se perceber que durante as férias de um funcionário as tarefas preventivas diminuem, e isso indica que ninguém assumiu as tarefas dele, ou que não são tão ágeis como ele; pode não representar um problema imediato, mas a médio ou longo prazo sim.

Por isso é importante que os números reflitam um período relativamente pequeno, ou possam ser comparados com um período anterior, para detectar anomalia.

5. Chamados por Importância ou SLA nos últimos 30/60/90 dias


Ter um indicador de quantos chamados são abertos com importância muito alta ou com SLA alto pode ser um indicador de problemas sérios na TI.

Por exemplo, se o padrão é ter apenas 20% de chamados com importância alta ou muito alta, e em um determinado mês esse número passa para 50%, pode indicar que a infraestrutura tem apresentado algum problema que está impactando negativamente o trabalho dos usuários.

Vale aqui, assim como no indicador anterior, que sejam vistos os chamados de um período apenas, como os últimos 30 dias, 15 dias ou até 7 dias. Se dissolver em um período muito grande, pode não ser possível detectar anomalias.

6. Nível de Satisfação dos Clientes nos últimos 30/60/90 dias

Esse indicador demonstra a satisfação dos clientes, mas o interessante aqui é demonstrar em um período recente, para detectar a alteração do mesmo.

Se tiver uma alteração, por exemplo, nos últimos 30 dias os clientes estiverem menos satisfeitos do que nos últimos 60 dias, deve-se tentar entender o que aconteceu e como reverter a situação.

Claro que, como toda pesquisa de satisfação de cliente, são poucos os que respondem, normalmente só os que estão muito satisfeitos ou muito insatisfeitos, por isso vale ações de incentivo para que os mesmos respondam as pesquisas quando receberem.

Esse indicador completa o primeiro indicador, se a qualidade do atendimento estiver boa e os clientes satisfeitos, pode ser considerado normal uma quantidade grande de chamados abertos.

Conclusão


Claro que esses indicadores só podem ser extraídos se o sistema tiver esses dados. O uso de um bom sistema de gestão de chamados e incidentes é importante.

O sistema de BI também deve dar o suporte adequado, sendo capaz de extrair os dados em tempo real (ou em intervalos de poucos minutos automaticamente), principalmente nos três primeiros indicadores, quando o gestor ou técnico tomar uma ação, os indicadores devem ser atualizados e refletir a nova realidade, imediatamente.

Também, fazer um pouco mais do que o básico, permite tomar ações corretivas enquanto os fatos estão acontecendo, melhorando a percepção de qualidade e satisfação dos clientes finais.


PS. estamos no ciclo final de desenvolvimento de um software para BI denominado Business Monitor, e nesse momento estamos recrutando usuários BETA, se estiver interessado, visite o site do produto e peça um contato:
EXTRAIA SEUS INDICADORES PARA OTRS E OCOMON

Sobre o autor
Fernando Ulisses dos Santos
Diretor de Tecnologia na Blue Solutions
Especialista em Segurança da Informação
Certificado VCP-DCV, VCAP-DT, VCP-DT

Nenhum comentário :

Postar um comentário

Business Intelligence em Radiologia: Ferramentas de Visualização de Dados

Nenhum comentário



Neste segundo artigo (leia o primeiro artigo aqui) sobre Business Analytics abordaremos algumas formas e ferramentas de visualização de dados utilizadas em sistemas de BI. Uma boa aplicação deve permitir ao usuário final rápida e clara identificação de padrões, status e alertas sem a necessidade de muitos cliques ou elaboração de planilhas e gráficos. Isso livra tempo para se analisar tendências e adotar estratégias de correção caso necessário (você poderia prontamente identificar um aumento no número de atrasos em determinado setor ou sala e logo agir para corrigir, antes que as queixas dos pacientes comecem a chegar, por exemplo). Por isso é importante que o software de analytics tenha boas views (como chamamos as telas ou páginas), cada uma com recursos visuais eficientes, rápidos e interativos, pois esse será o ambiente de trabalho e consulta dos usuários.

Dashboards (painéis de controle): ajudam as organizações a monitorar e administrar performances, medindo o progresso em relação a metas estabelecidas. A analogia é um painel de carro, ou cockpit de avião. Ponteiros, gráficos e sinalizadores que permitem uma fotografia (snapshot) do que está acontecendo naquele momento na empresa, setor ou clínica. É uma ferramenta tática, usada para obtenção imediata (at a glance) de insights e cenários. Você “bate o olho” num gráfico e percebe uma queda dos agendamentos nos horários noturnos, por exemplo. Por isso a importância de serem simples (não causar distração), focados em apresentar o dado de maneira que facilite a percepção visual.

Indicadores (icons): elementos gráficos que dão dicas sobre a performance. Um exemplo clássico são os ícones verde, amarelo e vermelho (traffic light).

Relatórios (reports): apresentação de dados brutos de maneira formatada e organizada visualmente, em forma de imagens estáticas ou planilhas interativas (permitindo filtrar, ordenar, selecionar e agrupar).

Alertas: são customizados para sinalizar e alertar de forma ativa determinado usuário ou grupo caso algum indicador atinja um valor definido. Podemos utilizar esse recurso para monitorar SLAs, indicadores críticos ou de segurança (reações adversas por exemplo).

Scorecards: visualização das metas e alinhamento estratégico da organização ou departamento, geralmente em forma de relatórios, com a utilização de ícones e outros indicadores de performance. Diferente dos dashboards, que representam a performance do momento, os scorecards representam o progresso longitudinal rumo a uma determinada meta ou objetivo. É onde, por exemplo, você vai definir que quer reduzir o uso de contraste em 20% em um semestre. Assim, por meio dos dashboards elaborados especificamente em função dessa meta em uma view (aba) “Uso de contraste” no seu BI, você poderá monitorar o progresso deste objetivo estabelecido no Scorecard da modalidade “Tomografia”. A constante revisão das metas nos scorecards associada à monitorização ativa da performance através dos dashboards, icons e reports vai permitir a escalada dos seus processos e ajudar no crescimento da empresa.

Artigo original por Thiago Júlio, MD, publicado no Jornal da Imagem

Nenhum comentário :

Postar um comentário

Gestão a Vista na Blue Solutions

Nenhum comentário
A Blue Solutions iniciou as atividades na Incubadora de Empresas de Araras em 2004. A Incubadora foi uma iniciativa da Prefeitura, Sebrae e Senai para fomentar as empresas na cidade, e como parte do programa oferecia consultorias sobre administração de empresas, financeiro, qualidade e marketing.

Inauguração Blue Solutions na Incubadora de Empresas de Araras - Os fundadores Edgar Teixeira Monteiro e Fernando Ulisses dos Santos



Mas, como a Incubadora tinha em sua maioria indústrias, a maioria dos consultores eram de indústrias, e quando chegavam na Blue Solutions encontravam uma realidade diferente, uma empresa puramente de serviços, mas mesmo assim traziam os conceitos já bem aplicados e conhecidos da indústria para aplicarmos em serviços, como 5S, Qualidade Total e entre eles Gestão a Vista.

No início fomos um pouco resistentes, mas para aproveitar as consultorias, acabamos por aderir a alguns indicadores, mesmo não adotando papel impresso na maioria, tínhamos acesso fácil, feito a partir de planilhas de controle específicas.

Quando graduamos na incubadora e mudamos para nossa sede nova em 2007, as consultorias ficaram para trás, e como a nova decoração não combinava com papéis colados na parede, abandonamos a prática quase totalmente.

Blue Solutions sede nova em 2007


Alguns anos depois, ao implantar o novo sistema de chamados baseado em ITIL, começamos a ter necessidades de relatórios e análises mais apuradas. Como o sistema era bem completo em informações, mas bem ruim em relatórios, buscamos formas de extrair esses dados do sistema, e foi quando tivemos nosso primeiro contato sério com softwares de Business Inteligence, que logo estava implantado para controlar chamados e vendas.

A experiência foi muito boa, mas sempre tivemos dificuldades em compartilhar os Dashboards do BI, pelo custo de licenciamento do mesmo e pela dificuldade de utilização, quando entregávamos para usuários mais leigos, eles acabavam aplicando filtros e se confundindo nas informações, por isso o BI acabou ficando restrito à diretoria.

Já em 2013 tivermos a chance de participar de uma nova consultoria do Sebrae, um programa para empresas já graduadas na Incubadora, e a consultora designada para nossa empresa voltou a tocar no assunto de Indicadores e Gestão a Vista.

De cara apresentamos nossos Indicadores no software de BI, os quais ela gostou muito, mas tinha um porém, não estavam a vista, e a a primeira ideia que veio foi colocar os mesmos em uma TV.

Já tínhamos a experiência anterior de usabilidade com usuários mais leigos, foi aí que começamos a nos empenhar para criar indicadores mais simples, e começamos a sentir que o software de BI utilizado era muito complexo e caro para ficar em uma TV ligado 24h.

Foi quando resolvemos fazer algum desenvolvimento interno para ter os indicadores, mas ao mesmo tempo que começamos a desenvolver os indicadores, não queríamos ficar amarrados a poucos gráficos, pois a Blue como qualquer negócio é dinâmico, e os indicadores precisariam, além de atualizar automaticamente, poder ser modificados com o passar do tempo sem precisar de muito mais desenvolvimento.

Terminamos por desenvolver uma ferramenta para uso interno, capaz de exibir indicadores, muito similar a um BI, mas voltado para Gestão a Vista, na qual montamos alguns Dashboards para Suporte, Vendas e Financeiro, e disponibilizando para todos os colaboradores.

Indicadores de Negócio para TI - Chamados e Técnicos


O que mais nos surpreendeu foram os resultados ao deixar os indicadores à vista, alguns números, como a quantidade de chamados abertos que antes não ficavam abaixo de certo número, mesmo com cobrança constante, passaram a entrar dentro do valor esperado por iniciativa da própria equipe. Outros indicadores também trouxeram benefícios, mas são assunto para uma próxima matéria.

Indicadores de Negócio para TI - Saúde dos Hosts


E o software que desenvolvemos? Alguns clientes viram nosso Dashboard e pediram algo similar dentro de suas empresas, fizemos mais alguns desenvolvimentos e estamos colocando hoje em alguns clientes uma versão de testes, em breve lançaremos no mercado.


CONHEÇA O BUSINESS MONITOR

Sobre o autor
Fernando Ulisses dos Santos
Diretor de Tecnologia na Blue Solutions
Especialista em Segurança da Informação
Certificado VCP-DCV, VCAP-DT, VCP-DT

Nenhum comentário :

Postar um comentário

Evento Blue Solutions e Dell

Nenhum comentário
No dia 04 de novembro, a Blue Solutions em parceria com a Dell realizaram o evento "Soluções Empresariais", na fábrica da Dell em Hortolândia/SP.




Os profissionais da Dell puderam mostrar maneiras de otimizar o ambiente de TI de uma empresa, através de soluções de servidores, networking e storage.


Foi uma ótima oportunidade para estimular o desenvolvimento de ideias e soluções e reunir os clientes da Blue Solutions.

Durante o evento Celso Bonilha apresentou as Soluções de Data Protection, Leandro Freitas falou sobre Inovações Dell Networking, Gustavo Andrade sobre Inovações em Servidores e por fim, Rodrigo Cabral apresentou Soluções de Armazenamento.




Todos ainda realizaram um tour na fábrica e tiverem a chance de conhecer mais de perto o processo de produção dos equipamentos da Dell.

A Blue Solutions sempre trabalha com a Dell para promover eventos como esse e muitos outros sobre diversos assuntos de interesse dos profissionais e empresas de TI.

Para ficar por dentro dos eventos da Blue Solutions entre no link abaixo e se inscreva para receber os convites:

Nenhum comentário :

Postar um comentário

O que é o DPACK e como utilizar?

Nenhum comentário

A Dell fornece aos clientes algumas ferramentas para gerar indicadores de demanda, como o DPACK (Dell Performance Analysis Collection Kit).


É um modo de auxiliar a análise da sua área de TI e dimensionar soluções de acordo com as suas necessidades. Assim, é possível diminuir gastos desnecessários e identificar oportunidades, otimizando o seu ambiente de TI.
O DPACK roda remotamente. Basta iniciar a execução da ferramenta em todas as máquinas de produção do seu ambiente e durante 24 horas.


Após a execução do programa é gerado um relatório do consumo de hardware que a estrutura demanda e alguma informações são obtidas, como:

  • I/O de disco
  • Throughput
  • Utilização de capacidade e memória
  • Workload dos servidores e necessidades de capacidade 




Assim, um especialista de soluções mostrará o impacto dos resultados coletados. 

E fique tranquilo, pois a execução da ferramenta não afeta o desempenho da rede e é gratuita.
Para fazer o download da ferramenta entre no link abaixo:
http://www.dell.com/dpack

Siga passo a passo, desde o download até a execução da ferramenta DPACK, seja no Linux ou no Windows:
 



 


Após o download da ferramenta, veja os passos até o início da execução:

 







Para saber mais detalhes, faça o download do Guia do Usuário (User's Guide), no link abaixo:
http://www.bluesolutions.com.br/promo/Dell-Performance-Analysis-Collection-Kit-DPACK.pdf

Após a coleta de dados, o processamento pode ser feito pela própria Dell, ou por um parceiro especializado como a Blue Solutions.

Se quiser, fazemos o processamento gratuitamente, envie os arquivos coletados para uma conta sua no Dropbox ou serviço similar, e clique no botão abaixo para nos enviar.

Nenhum comentário :

Postar um comentário

Blue Solutions e Dell realizam o evento Toad Latam Tour

Nenhum comentário


A Blue Solutions em parceria com a Dell realizaram o Toad Latam Tour, no dia 23 de Outubro de 2014. 




O evento aconteceu no Octávio Café, em São Paulo, e contou com a participação dos diretores da Blue Solutions Edgar T. Monteiro e Fernando Ulisses dos Santos, além da presença de diversos clientes.



O tema do evento "Aumente a produtividade e melhore o rendimento de suas Bases de Dados" foi explorado e o público compreendeu de que forma podem ampliar e melhorar o uso de dados nas tomadas de decisões dos negócios da sua empresa.


Ainda, o gerente mundial dos produtos Dell da linha de Information Management, Daniel Norwood, ministrou uma palestra e falou sobre inovações, lançamentos e vantagens da utilização da tecnologia em uma empresa.

Foram apresentadas as ferramentas Toad for DBA, Shareplex e Toad Data Point.



Após o evento aconteceu um Happy Hour bem descontraído com os participantes.


Foi um encontro muito interessante e agradável! Confira mais fotos:







Nenhum comentário :

Postar um comentário

Os 7 Erros Básicos que até Profissionais cometem em Projetos de Virtualização

2 comentários
7 Erros

Tenho trabalhado com projetos de virtualização praticamente desde que surgiram os primeiros hypervisors baremetal, e já encontrei ambientes em clientes de várias formas, alguns muitos corretos, alguns sub-dimensionados, outros super-dimensionados, algumas configurações bobas erradas, até conceitos errados aplicados.

Mas existem alguns erros que são básicos, muitas vezes feitos por falta de entendimento da tecnologia, outros por medo de errar ou por distração.

São esses erros que você deve observar em seu ambiente, tem uma chance de 50% dos ambientes ter esses erros, alguns são muito fáceis de serem corrigidos.

1) Falta de redundâncias

É comum em pequenas empresas, ao chegar um novo servidor, decidirem iniciar o mesmo virtualizado. Até aí tudo ok, mas depois vem a demanda, e como o ambiente já está ali, subir mais 2, 3 ou 4 VMs está fácil. Quando menos percebe, tem 10 VMs rodando no mesmo servidor físico, sem redundância nenhuma.

Pode não ter problema nenhum de performance, as VMs podem ser simples, mas são tudo que a empresa tem e precisa para trabalhar. Na falha desse servidor, vai dar muuuiito trabalho para recuperar o ambiente.

E quando chega nesse ponto, normalmente o ambiente já depende dessas VMs, o backup é inadequado e podem até existir algumas licenças irregulares.

Não é culpa da virtualização, faltou um plano diretor de TI para guiar o crescimento e investimentos. A ferramenta permitiu atender a demanda do negócio, agora é hora do negócio reinvestir na infraestrutura para suportar o crescimento futuro.

Nesse caso, não tem jeito, a saída para a empresa é investir na adequação do ambiente e compra das redundâncias necessárias. Cabe à equipe de TI demonstrar os riscos existentes e a importância da infraestrutura para o negócio, daí uma análise de riscos pode ajudar bem.

2) Super Dimensionamento das máquinas virtuais

É comum em um ambiente novo de virtualização o administrador de redes querer dar todo o desempenho possível para as novas máquinas virtuais. Até numa migração, é comum fazer um P2V de máquinas físicas de 2 gerações de processadores atrás, que já tinham 4 núcleos, para VMs com 4 ou mais núcleos.

Mas é incorreto entregar a mesma quantidade de núcleos em uma VM depois de um P2V; mesmo ao criar uma VM nova, também não é boa prática começar com muitos núcleos.

Só para comparação, um servidor com processadores de duas gerações atrás: Dual Xeon E5520 que roda a 2.27Ghz tem um score de processamento de 7.590, enquanto que um processador moderno Xeon: E5-2630 v2 que roda a 2.6Ghz tem um score de processamento de 15.697, é mais do que o dobro da capacidade de processamento! Sem contar que o mais novo tem 6 núcleos versus 4 do antigo, maior velocidade de transferência para a memória e quase o dobro de cache interno.

http://ark.intel.com/pt-br/products/64593/Intel-Xeon-Processor-E5-2630-15M-Cache-2_30-GHz-7_20-GTs-Intel-QPI

http://ark.intel.com/pt-br/products/40200/Intel-Xeon-Processor-E5520-8M-Cache-2_26-GHz-5_86-GTs-Intel-QPI

O processador mais novo já vai deixar a VM mais rápida, por isso a recomendação é que, depois de uma migração de ambiente, seja via P2V ou instalação nova, as VMs sejam iniciadas com o mínimo de vCPUs, memória e disco possível e vá crescendo sob demanda.

Um estudo recente indica que 95% das VMs são superdimensionadas, isso mostra claramente esse problema, e é possível que na sua infraestrutura existam máquinas virtuais superdimensionadas.

O problema que isso gera é que, ao iniciar todas as VMs consumindo todos os recursos ambiente, sobra pouco espaço para manobras, e na prática, não é necessário. Corre até o risco de criar problemas de Ready Time (que será tratado em outro artigo) e falhas no HA (High Avaliability) por falta de recursos.

Por isso vale a pena acompanhar os indicadores de uso de CPU de todas as VMs, principalmente as menos importantes, e o tempo de CPU Ready, para entender se seu ambiente tem gargalho causado por superdimensionamento das máquinas virtuais.

3) Super Dimensionamento dos servidores hospedeiros

Por medo de errar e por não conhecer o ambiente, muitos projetos de virtualização acabam super dimensionados em recursos dos hosts físicos.

Embora não crie problemas diretos no projeto, e, se comprado, irá rodar tudo bem, a grande dificuldade dos projetos superdimensionados são os alto custos de aquisição, que podem inviabilizar o mesmo e manter recursos ociosos por vários anos até o ambiente crescer e ocupar essa capacidade.

Por isso é importante executar ferramentas de análise no ambiente antes de fazer um projeto (como o Dpack), para que o sizing do projeto não seja exagerado e possa apresentar um bom custo X benefício.

Como a virtualização permite o crescimento de Configuração das Máquinas Virtuais, Hosts Físicos, Espaço em Disco e Performance de Disco sem muito esforço, o recomendado é que os investimentos sejam feitos gradativamente, comprando uma parte da capacidade a cada ano.

Isso permite aproveitar a Lei de Moore a seu favor, a cada um ano e meio, cada novo host, storage ou outro componente comprado poderá ter o dobro da capacidade, pelo valor do componente da geração anterior.

Claro que isso não resolve para empresas que já tenham o ambiente muito sub-dimensionado, ou onde o financeiro não vê vantagem em ter compras constantes e prefere uma compra grande financiada, mas se a TI puder programar as próximas compras com o decorrer do tempo, com certeza terá benefícios.

4) Subdimensionamento do ambiente, principalmente de disco

Essa é meio óbvia se pensarmos bem e muitos profissionais alocam CPU e memória em excesso para evitar, mas quando fala-se de disco, é bem comum vermos esse erro.

Existe até um ditado que diz que os projetos de Virtualização tem metade dos discos que precisa, o dobro da memória e 10 vezes a CPU que precisa.

Exageros a parte, depois de acompanhar dezenas de projetos, percebi que isso é a mais pura realidade. Por algum motivo, a CPU é a principal preocupação de muitos profissionais e acaba super dimensionada.

Normalmente a camada de armazenamento (discos e Storage) é subjulgada e é a primeira que acaba. O crescimento de discos frequentemente é calculado como linear, quando na prática é exponencial.

Outro erro básico para os discos é fazer a conta somente em Gigabytes. Olha-se o ambiente atual, por exemplo, 10 servidores com 2 discos de 144Gb em RAID 1 cada, multiplica-se, chega a 1,4Tb de espaço disponível no cenário atual, calcula-se o dobro prevendo o crescimento: 3Tb.

Para fazer 3Tb são necessários apenas 8 discos de 900Gb em RAID 10... mas existiam 20 discos anteriormente, e agora com apenas 8 discos vai ter problema de performance na certa.

Mas também não é correto fazer o projeto com 20 discos como era no ambiente original, vai voltar ao problema de superdimensionamento.

Para não errar para mais nem para menos, é preciso medir os IOPS (quantidade de operações de disco por segundo) usados no ambiente e fazer a projeção.

Talvez nem precise dos 8 discos, ou talvez precise de 16, aí pode-se optar por ter mais espaço em disco (16 discos de 900Gb) ou manter os custos com mais discos de menor capacidade (16 discos de 600Gb).

5) Licenciamento de Aplicações

Não é mais tão comum, mas algumas aplicações podem ter o licenciamento vinculado com a máquina física, independente do ambiente virtual. Outras aplicações podem exigir o licenciamento de todo o Cluster virtual, independente de qual servidor a aplicação está rodando efetivamente.

Esse é um item que deve ter atenção dobrada, até para não pagar exageros de licenças. Às vezes pode ser vantajoso manter uma aplicação, mesmo virtualizada, fora do Cluster, apenas para não pagar as licenças excedentes.

Outras vezes, o uso de licenças de nível Enterprise de um software permitem a instância de múltiplas VMs sem custos adicionais, diferente de licenças básicas que precisam ser licenciadas por VM.

6) Configuração de rede sem redundâncias

Esse é um aspecto bem técnico, e realmente precisa de um especialista para fazer corretamente, mas fico impressionado com a quantidade de implementações que encontro com essa falha, mesmo com tanta documentação existente.

É comum encontrar mais de uma interface de rede conectada, mas cada uma para um propósito diferente, com uma VLAN diferente que foi configurada no Switch físico, ou com um link de Internet fixo em uma porta do servidor ESX.

O problema disso é que não existem redundâncias no ambiente, e no caso de um ambiente com vMotion licenciado, não é possível fazer a movimentação das máquinas virtuais entre servidores hospedeiros sem interromper o serviço.

Essa configuração também limita a performance do ambiente, já que existe apenas um canal de comunicação entre o ESX e cada VLAN, sendo que poderiam existir dois ou mais.

A configuração a ser feita é bem simples, no VMware ESX principalmente, uma configuração recomendada é usar no mínimo duas interfaces de rede conectadas ao Switch, e com essa configuração, adicionar ambos os adaptadores no mesmo Switch Virtual, depois configurar as VLANs como Port Group e conectar as máquinas virtuais que precisam de acesso a essa VLAN no Port Group.

É uma alteração simples, mas que pode fazer toda a diferença para a disponibilidade do ambiente.

7) Não monitorar a infraestrutura adequadamente

O uso de ferramentas de monitoramento que não entendem o ambiente virtual pode levar a diagnósticos incorretos.

Ter os plugins para o ambiente virtual e capacidade de análise do mesmo é fundamental para as ferramentas de monitoramento.

Para isso, ferramentas específicas para o ambiente virtual como o VMware VCenter Operations Manager são fundamentais e devem ser consideradas na aquisição da solução.

Mesmo ferramentas tradicionais já possuem plugins para virtualização, e esses plugins devem ser instalados e configurados corretamente para monitorar todo o ambiente.

Conclusão:

Alguns dos erros são menos óbvios, e podem passar desapercebidos até o ambiente começar a ter problemas de performance. A solução daí será aumentar os investimentos de forma abrupta, quando poderia ser feito de forma planejada e gradativa.

Outros casos, simples configurações podem resolver, mas por falta de conhecimento da ferramenta, pode-se optar até por situações extremas, como um único Host físico com uma única máquina Virtual, ou tirar um determinado serviço da Virtualização.

Por isso recomendamos a contratação de equipes especializadas, capacitadas pelos fabricantes, ou então fazer cursos especializados em ambientes virtuais para a criação e manutenção de um ambiente virtualizado profissional.

E você, já viu esses erros em algum ambiente? Acha que esqueci algum importante?

2 comentários :

Postar um comentário

O que são IOPS, como calcular, e porque são importantes para meu projeto de TI?

Nenhum comentário

Uma palavra que apareceu nos últimos anos nos projetos de TI foi IOPS, e embora alguns fornecedores já comecem a medir a mesma e considerar nos projetos, nem sempre são entendidas e calculadas corretamente.

IOPS é uma abreviação para Input/Output per Second, ou operações de entrada e saída por segundo, aplicada sobre dispositivos de armazenamento, como drives de discos, drives SSD e Storages.

Sua importância para os projetos de TI é que ele indica quantas operações de leitura e escrita o dispositivo é capaz de realizar por segundo e essa quantidade impacta diretamente na performance.

Novos HDDs tem sido vendidos com cada vez mais capacidade de armazenamento e podem dar a sensação de que precisamos de menos HDs para compor a solução, mas um determinado ambiente precisa de uma determinada performance e só é possível alcançar a performance adicionando a quantidade adequada de discos.

O problema: leis da física


O problema de performance dos drives de disco se dá por limitações físicas mesmo, veja a situação da figura abaixo, onde o HDD girando no sentido horário precisa ler as informações localizadas nos pontos 1, 2 e 3.

Leitura Aleatória em HDDs
Para fazer a leitura nessa sequência, o HDD precisa dar quase uma volta inteira para cada bloco. Considerando um HDD que trabalha a 7200 RPM (rotações por minuto), uma volta demora cerca de 8,3ms, esse é o tempo mínimo entre essas leituras, o que permitiria até 120 leituras por segundo.

Só que, como o bloco 2 é em um extremo do HDD e o bloco 3 é em outro extremo, pode ser que a cabeça de leitura não se movimente rápido o suficiente para ler o bloco 3, o que obriga a cabeça a esperar por mais uma volta para fazer a leitura do dado, reduzindo a capacidade de leituras por segundo.

Assim, o cálculo de IOPS de um disco é dado pela fórmula:

Fórmula para Cálculo de IOPS


Onde Rotational Latency  é o tempo de espera até o disco girar onde precisamos ler o dado, e Seek Latency é o tempo de deslocamento da cabeça de leitura até o ponto no HD. Divide-se por mil para ter o número em segundos, pois normalmente os outros dois parâmetros são indicados em milissegundos pelos fabricantes.

Claro que, numa situação ideal, onde os dados estão alinhados, as latências de rotação e de procura diminuem, aumentando a capacidade de leitura dos HDs, mas isso só é possível em situações bem particulares, com um HD sendo acessado por uma única aplicação que tenha os dados alinhados corretamente, o que não acontece em um ambiente de desktop ou servidor comum.

Leitura Sequencial em HDDs

Discos mais rápidos

Discos de 15000 RPMs são mais rápidos que discos de 10000 RPMs ou 7200 RPMs, pois em um disco de 15000 RPMs, o tempo para dar uma volta completa é de 4ms, versus 6ms em discos de 10000 RPMs, 8,3ms em discos de 7200 RPMs, 10,1ms em discos de 5900 RPMs e 11,1ms em discos de 5400 RPMs (usado em notebooks e desktops de baixo custo).

Também, discos de 2,5" são ligeiramente mais rápidos do que discos de 3,5" com a mesma capacidade, pois a cabeça precisa movimentar menos para passar por toda a área útil do disco, trazendo um ganho de 20% a 30%.

E ainda os discos com maior capacidade (600Gb versus 146Gb por exemplo) podem ser mais rápidos quando usada a mesma quantidade de dados. Isso é comum depois de uma migração, por exemplo, se tiver 100Gb no servidor antigo com discos de 146Gb, ao migrar para um servidor novo com discos de 600Gb, os mesmos 100Gb estarão posicionados no início do HD, exigindo muito menos movimentação da cabeça de leitura.

Uso de disco versus IOPS
Isso também explica porque depois de uma desfragmentação do disco, a performance melhora significativamente.

Alternativas


Uma das alternativas para acelerar os drives de discos seria aumentar a velocidade, mas experimentos feitos a 20000 RPMs indicaram que os discos seriam mais sensíveis a vibrações, podendo apresentar defeitos mais facilmente, além de consumir mais energia elétrica e aquecer mais.

Outro fator contra acelerar os discos é a limitação da capacidade, quanto mais rápido a rotação, menor a densidade de trilhas por polegada. Para se ter ideia, um disco de 2Tb tem 236000 trilhas por polegada.

Outra alternativa seria acrescentar duas ou mais cabeças de leituras independentes, como já até existe patente para isso, propriedade da Seagate, mas os custos de fabricação seriam maiores, o espaço do HD seria maior  (deixando os novos HDs incompatíveis com os equipamentos atuais), consumiria mais energia elétrica e geraria mais calor.

HDD de duas cabeças

A possibilidade é que com duas cabeças de leitura tivesse um ganho de até o dobro de IOPS para a mesma capacidade e rotação de disco, pois o tempo de rotação poderia ser cortado pela metade (já que cada cabeça está em um lado do disco) e a capacidade de deslocamento da cabeça seria o dobro, pois existem duas.

Mas já que duas cabeças independentes não é possível por questões de mercado, os fabricantes poderiam no mínimo considerar dois leitores na mesma cabeça, isso reduziria o Seek Time pela metade, a cabeça teria que movimentar apenas metade do percurso, diminuindo o consumo de energia e gerando ganhos de IOPS de até 50%.

HDD com cabeça alienígena

Como nenhuma dessas soluções são cogitadas hoje pelos fabricantes, ficamos com a solução mais "convencional" de performance.

A solução do mercado para performance

Mais memória nos servidores, mais cache nos HDs não resolvem a limitação física dos drives de disco (HDD ou Hard Disk Drives), por isso muitos fabricantes tem incluído SSD (Solid State Drives) nas soluções, para atingir a performance necessária pelas aplicações.

Para comparação, esses são os números de IOPS médios dos HDs de mercado:

IOPS por tipo de disco

Pode-se observar que os discos mecânicos, por mais rápidos que sejam, não chegam nem perto dos drives SSD em quantidade de IOPS.

Mas os drives SSD também são bem mais caros por GB, então, uma solução ideal deve incluir discos SSD e HDD para balancear entre custo de aquisição, espaço disponível e performance

A solução ideal também deve incluir software inteligente o suficiente para mover os dados mais acessados para os discos mais rápidos e os dados menos acessados para os discos de maior capacidade.

Juntando tudo numa solução

A melhor parte ao montar um projeto é que podemos somar a performance de vários discos usando RAID (Redundant Array of Independent Disks).

Por exemplo, com RAID 0 em dois discos de 7200 RPMs, os dados são distribuídos em ambos os discos por igual, isso permite atingir a velocidade de até 150 IOPS, que seria alcançada apenas com um disco de 15000 RPMs, mas o custo de aquisição para a mesma quantidade de espaço pode ser menor usando discos de 7200 RPMs.

Claro que não recomendamos usar RAID 0 numa solução empresarial, por isso veja o exemplo abaixo com RAID 10 e RAID 5:

Cálculo de IOPS com RAID


Os dois cenários apresentados são bem parecidos em espaço disponível e performance, mas a chance é que o cenário 1 com discos de 7200 RPMs seja bem mais em conta que o cenário 2 com discos de 15000 RPMs.

Existem outros fatores a serem considerados, 6 discos consomem mais energia, geram mais calor e tem maior probabilidade de quebra do que 4 discos, mas o RAID 10 utilizado é mais seguro. Em um projeto de poucos servidores o cenário 1 é sem dúvida mais vantajoso, em um projeto com centenas de servidores, o cenário 2 deve ser considerado.

Quantos IOPS preciso no meu projeto?

Essa é a pergunta chave. O ideal é que o fornecedor do sistema informe quantos IOPS são necessários por usuário conectado no sistema, daí você pode fazer a projeção de crescimento e calcular os IOPS necessários no ambiente.

Mas, o mesmo sistema, rodando em empresas similares, pode ter comportamentos diferentes por pequenas alterações, e, na prática, poucos fornecedores de sistemas estão prontos para medir e recomendar essa informação.

Então, a melhor forma é medir a quantidade de IOPS utilizado no ambiente atual e fazer o projeto baseado nessa análise.

É possível utilizar ferramentas do próprio sistema operacional, no Windows basta usar o Performance Monitor, e no Linux usando um utilitário como o iotop.

Depois de saber quantos IOPS são necessários, basta fazer o cálculo de quantos discos são necessários usando essa ferramenta.

Outra alternativa para medir o seu ambiente é usar o utilitário DPACK da Dell. Embora o aplicativo seja grátis para uso, é necessário envolver um parceiro Dell para processar os resultados e gerar os gráficos.

A Blue Solutions realiza o processamento dos dados do DPACK gratuitamente, entre em contato no formulário abaixo:



Enviar Dados para Análise

Nenhum comentário :

Postar um comentário

Windows Server 2012 com Hyper-V Replica

Nenhum comentário
O Hyper-V do Windows Server 2012 introduz uma nova funcionalidade, o Hyper-V Replica, como um mecanismo de replicação embutido de máquinas virtuais. Hyper-V Replica faz a replicação de forma assíncrona de uma máquina virtual em execução hospedada em um site de produção para um site de DR através da LAN/WAN.


Neste cenário tanto os sites primários quanto os sites secundários deverão utilizar o Windows Server 2012 ou 2012 R2, onde o site primário estará com todas as VMs em produção, enquanto o site secundário irá receber as VMs replicadas (DR) do site de produção. Assim, caso o site principal tenha algum problema ou uma queda de VM planejada ou não, as VMs poderão ser ligadas no site secundário, podendo ser apenas uma VM em pontual, como também todas as VMs do site. 

O Hyper-V Replica não necessita de armazenamento compartilhado, nem de hardware de armazenamento específico. Uma vez que uma cópia inicial é replicada para o site secundário a nível de LAN a replicação já estará configurada, assim, com o agendamento da replicação o Hyper-V irá replicar apenas a diferença da VM para o site secundário, ou seja, os deltas, e ocorrerá de forma assíncrona, podendo ocorrer em um tempo de no mínimo 30 segundos.


Habilitando a replicação para o Servidor DR

Uma vez que todas as exigências são configuradas, a primeira etapa a se configurar é o servidor de destino (réplica); em seguida configurar as VMs que serão destinadas para a replicação, conforme segue o processo de exemplo para habilitar Hyper-V Replica.
 

Primeira Etapa 

Identificar quais os Hosts com Windows Server 2012 Hyper-V que irão receber as réplicas e através do "Hyper-V Settings", acessar as "Configurações de Replicação" e validar suas respectivas configurações.






Segunda Etapa 

Através do Hyper-V Manager no site principal, clicar com o botão direito do mouse nas VMs a serem replicadas e acessar "Habilitar Replicação"; em seguida, através do assistente de configuração seguir as melhores práticas para o ambiente.

 



 

A primeira replicação poderá ocorrer na conclusão da configuração, como também pode ser agendado.

A replicação ocorre via LAN. A melhor prática para replicação inicial é
agendar horários menos críticos, pois é neste momento que será replicado o arquivo com o tamanho total de cada VM.

Caso a VM possua um disco com tamanho muito grande temos a opção de armazenar a primeira replicação em um disco físico (HD Externo), em seguida, transportar para o Site DR e armazenar o mesmo. Após esta etapa, a replicação será apenas dos deltas, ou seja, incremental.

Também nesta configuração temos a opção de criar pontos de failover, ou
seja, podemos criar vários pontos. Assim, podemos escolher no failover em qual momento iremos retornar a VM replicada.

Assim a configuração estará concluída. Esta tarefa deverá ser realizada em todas as VMs que farão parte da replicação.

Obs.: como a replicação ocorre a nível de kerberos é de extrema importância que o ADDC e DNS estejam funcionando corretamente.
 

Podemos realizar um teste de failover a partir do site Secundário (DR). Clique com o botão direito do mouse na VM replicada e selecione a opção "failover test" assim, o Hyper-V cria uma VM com o mesmo nome da VM do site de produção, basta iniciar a mesma.

A VM será iniciada sem IP, ou seja, apenas teste, porém um recurso bastante interessante, na qual temos a possibilidade de configurar IP Failover. Ou seja, quando iniciarmos a VM no site DR podemos iniciar a mesma com outro IP.

Failover Planejado, se destina para um ambiente ou máquina virtual com possível problema, na qual iremos executar a opção "Planned Failover". Esta opção irá ligar a VM no site DR, ou seja, esta opção apenas deverá ser executada caso a VM de produção esteja com algum problema ou desligada.




As informações, a seguir, são retornadas após uma execução bem-sucedida de um evento planejado de Failover a partir do site secundário (DR).





A execução com sucesso de um failover planejado irá estabelecer automaticamente uma relação de replicação inversa onde, em seguida, o local antes de réplica (DR) torna-se o principal (produção) e o local atual de produção se torna réplica (DR). Verifique a saúde da replicação clicando com o botão direito na VM; com o Hyper-V Replica habilitado, clique em "Hyper-V Manager", que revela a relação da replicação atual. A seguir, são mostradas informações de saúde da replicação da VM antes e depois de realizar com sucesso um failover planejado, com uma relação inversa (replicação definida automaticamente).


O failover sempre deverá ser iniciado manualmente no site DR após a identificação de que uma VM ou o site principal como um todo está com problema. 

Caso o problema esteja no Host, deverá ser efetuado o failover de todas as VMs no site secundário. Assim, quando o Host voltar em seu perfeito funcionamento irá desligar as VM e efetuar o failback, do secundário para o primário.


INFORMAÇÕES

Replicação assíncrona de mudanças

O Hyper-V Replica irá replicar, ou seja, criar uma VM idêntica no Gerenciador Hyper-V do servidor de réplica, e posteriormente, o Hyper-V Replica, irá rastrear, acompanhar os processos e reproduzir as alterações no site secundário.

Esta tarefa irá ocorrer independente dos arquivos VHDs, ou seja, podendo ser de origem de compartilhamento (SMB), Cluster Shared Volumes (CSVs), SANs ou dispositivos conectados diretamente ao Hyper-V.


Hyper-V Replica com Cluster

Se o ambiente possuir um cluster de failover do Hyper-V como um site DR, deve-se utilizar a função Failover Cluster Manager para realizar todas as configurações e gerenciamento do Hyper-V Replica, sendo que primeiro deve-se criar uma função Hyper-V Replica Broker, conforme demonstrado abaixo. 


  

O Hyper-V Replica Broker é o ponto selecionado nesta imagem. Ele consulta o banco de dados de cluster associado e redireciona para o melhor nó as VMs e eventos específicos, tais como pedidos de migração ao vivo em um cluster de réplica. 

Active Directory

Domínio do Windows Active Directory não é um requisito para o Hyper-V Replica, que também pode ser implementado entre grupos de trabalho e domínios não confiáveis através de uma autenticação baseada em certificado. O Active Directory, no entanto, é um requisito muito importante no host Hyper-V quando o mesmo faz parte de um cluster de failover, nesse caso, todos os hosts Hyper-V de um cluster de failover devem estar no mesmo domínio do Active Directory, com segurança aplicadas no nível do cluster.

Autor: Alex Santos - Especialista Blue Solutions


Nenhum comentário :

Postar um comentário