MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Pageviews The process cannot access the file 'D:\home\site\wwwroot\Visitas2.xml' because it is being used by another process. 2019: 577846
Pageviews 2018: 4296564
Pageviews 2017: 4351543
Pageviews 2016: 3991973
Pageviews 2015: 2675433
Pageviews 2014: 2664208
Pageviews 2013: 2399409
Pageviews 2012: 3209633
Pageviews 2011: 2730038
Pageviews 2010: 1470924
Pageviews 2009: 64608

Últimos posts

Categorias

Arquivo

Tags

System Center 2019 e Windows Server 2019 – Upgrade in place II

Com o lançamento oficial do System Center 2019 semana passada agora já podemos testar a migração da versão final.

https://cloudblogs.microsoft.com/windowsserver/2019/03/07/coming-soon-microsoft-system-center-2019/

Nova Politica de Versões

Na nova politica de versões do System Center, não haverá os canais Semi-Anuais como Windows.

Ou seja, você terá a versão 2019 por aproximadamente 3 anos com os updates que em geral ocorrem 3 vezes por ano.

Isso significa que diferente das primeiras versões que foram o 1801 e 1807, daqui em diante não teremos mais esse mesmo tipo de nomenclatura retornando ao antigo modelo de versões com updates (2019 UR 99).

Importante: System Center Configuration Manager continua com o canal Semi-Anual

https://docs.microsoft.com/en-us/system-center/ltsc-and-sac-overview

Executando o Upgrade

No mesmo documento acima, vemos o suporte para upgrade in-place que é garantido até as ultimas 2 versões.

Isso significa que os usuários das versões 2012 R2 precisarão primeiro fazer o upgrade para a 1801 e depois para o SC 2019.

Importante: System Center Configuration Manager terá as regras de update diferentes, dependendo do canal escolhido

Assim como o upgrade da versão 2016 para a 1801 foi tranquila e já demonstrei aqui http://www.marcelosincic.com.br/post/System-Center-2019-e-Windows-Server-2019-Upgrade-in-place.aspx, a migração do 2019 tambem foi bem satisfatória.

Todos eles precisamos apenas confirmar a instalação, apenas com excessão do SCOM e VMM que é necessário o upgrade de agentes.

O DPM não executei o upgrade pois atualmente utilizo o Microsoft Azure Backup que é um subset especializado para backup no Azure.

System Center Operations Manager (SCOM)

SCOM (2)

SCOM (3)

No caso do SCOM uma mudança é agora poder ativar pela interface no “About”, antes era necessário fazer pelo PowerShell com o comando Set-SCOMLicense.

SCOM (1)

Lembrando que no caso do SCOM é necessário autorizar o upgrade do agente para todos os servidores logo após a instalação. Caso não o faça continuará havendo comunicação, mas ele irá criar alertas constantes de aviso e novos recursos podem ocasionar falha nos agentes.

System Center Service Manager (SCSM) e System Center Orchestrator (SCO)

Literalmente nada precisou ser feito ou alterado e o mesmo aconteceu com o Orchestrator.

Service Manager (1)

Service Manager (2)

System Center Virtual Machine Manager (SCVMM ou VMM)

O VMM já exigiu um pouco mais de trabalho, pois é necessário rever as contas no “Run-AS” que agora limita contas locais e reinstalar os agentes.

No meu caso, fiz o exercicio de desinstalar para validar se apenas utilizando o banco de dados retornaria e funcionou!

VMM (1)

VMM (2)

VMM (3)

VMM (4)

Azure Virtual Datacenter (VDC) Parte II-Conceitos Básicos

No post anterior falamos sobre a migração para Cloud http://www.marcelosincic.com.br/post/Azure-Virtual-Datacenter-(VDC)-Parte-I-Migracao-AS-IS-e-TO-BE.aspx 

Neste post vamos entender os conceitos básicos, que são representados por esse diagrama:

image

Cada parte representa um dos pilares que sustentam um Datacenter Virtual:

  • Encriptação – Todos os dados trafegados dentro de um datacenter onde vários clientes se hospedam precisam ser protegidos de forma que um não tenha acesso aos dados de outros. Isso envolve criptografia de comunicação, discos e trafégo
  • Identity – Um modelo consistente de identidade onde os clientes consigam se logar e ver seus objetos com todos os recursos disponiveis. No caso do Azure isso é feito pelo Active Directory multi-tenant (multi locatário). Como já conhecido no mercado sistemas de diretório permitem que multiplas empresas estejam hospedadas e compartilhem o modelo de banco de dados e autenticação com total isolamento
  • Software-Defined Networks – Como hospedar vários clientes se todos querem ter o mesmo range de IP e se comunicam pelos mesmos conjuntos de cabos?
    Esse é o desafio das SDNs, permitir trafego isolado. No passado faziamos isso com o recurso de VLAN mas era limitado a 65535. Hoje isso é feito de forma lógica por usar recursos como o NVRE e outros onde os pacotes de rede são tageados (marcados) a quem pertence, similar ao que a VLAN fazia mas sem o limite de 32 bits.
    Isso permite que multiplos clientes tenha o mesmo range de IP 10.0.0.0/24, já que cada rede virtual recebe um diferente TAG nos pacotes, com a criptografia e identidade garantindo a confiabilidade na entrega dos pacotes de dados
  • Compliance – De nada adiantaria se ao migrar para um datacenter público você ficasse preso a padrões que só funcionam lá. As clouds publicas precisam adotar os padrões de mercado para as redes se comunicarem. Isso não quer dizer que a forma como o Machine Learning da Microsoft é codificado é igual ao Machine Learning da AWS, mas sim que a parte básica segue padrões de interoperabilidade.
    Por exemplo, uma VMs na AWS pode se comunicar por IP com uma VM no Azure ou no Google Cloud, pois todas usam os mesmos protocolos, mesmo que um provedor tenha serviços agregados diferentes.
    O mesmo vale para uma aplicação em Moodle ou SAP, se está no Azure ou AWS não importa pois seguem os padrões de rede e comunicação (interchange) identicos.
    Por conta do compliance que posso deixar metade dos meus servidores local e os outros espalhados em 3 diferentes datacenter publicos e todos se comunicando normalmente.
  • Logging, Audit e Report – Ao migrar de uma nuvem privada (local) para uma pública preciso saber os custos e ter certeza que meus dados estão seguros e acessados só pelos meus usuários.
    Aqui não estamos tratando de log, auditoria e reports para o cliente e sim a infra interna para que o provedor tenha certeza que não há vazamento de dados, quem fez cada operação e reportar isso quando necessário.
    Por isso os cockpits de provedores de cloud pública são gigantescos. Precisam controlar e serem capazas de se refazer em qualquer tipo de falha que ocorra.
    Os primeiros datacenters surgiram do conceito de hosting, ou seja você tirava os servidores do seu rack em casa para levar ao provedor onde a eletrica, links e segurança fisica ficam por conta deles. Nesse modelo toda a responsabilidade de comunicação, segurança lógica e relatórios é sua.
    No modelo público uma boa parte dos recursos são alocados para controlar os recursos, por exemplo ao criar o antigo Microsoft Azure Pack (atualmente descontinuado) várias VMs eram criadas com o objetivo de fornecer os itens de controle.

Conclusão

Nesse segundo post falamos sobre os componentes básicos que formam uma cloud pública.

Sinta-se seguro ao colocar seus dados nesses provedores, eles são preparados para garantir o isolamento e segurança dos seus dados.

Azure Virtual Datacenter (VDC) Parte I- Migração AS IS e TO BE

Quando trabalhamos em um projeto de migração para Public Cloud e o desenho é voltado a Azure, é muito comum os cenários de “AS IS”.

AS IS

Para os não iniciados com este termo, “AS IS” significa levar como está me ingles, ou seja copiar as VMs de um ambiente a outro sem qualquer alteração, utilizando o Azure como um virtualizador.

Em geral os modelos de migração AS IS não são eficientes, pois consomem muito recursos em IaaS (VMs) que custam caro, não aproveitando nada de serviços (SaaS ou PaaS) que são mais baratos. Porem, a vantagem é que é mais rápido e não exige mudanças.

TO BE (ou LIft and Shift)

Já as boas migrações são as “TO BE”, que em tradução livre seria “SERÁ” no sentido de transformação. O modelo de migração TO BE tem como premissa usar os serviços e não apenas migrar VMs.

Migrações TO BE são trabalhosas e mais demoradas, uma vez que esse mapeamento envolve entender o que está DENTRO DAS VMs.

O custo de execução é muito menor pois SaaS e PaaS tem vantagens financeiras grandes quando comparados ao modelo de IaaS.

Por exemplo, no AS IS um servidor IIS e outro de SQL serão simplesmente copiados os discos virtuais e iniciados. Já no modelo TO BE iremos isolar cada uma das aplicaçÕes que o IIS executa e criar Web Plan para isolamento e Web Services para cada site, e no caso do SQL Server usariamos o serviço de Banco de Dados (SaaS ou PaaS).

Utilizando o Service MAP

O primeiro passo para fazer uma migração é mapear o que cada VMs ou servidor fisico executa no ambiente.

Para isso utilizamos o Service MAP: http://www.marcelosincic.com.br/post/Azure-Log-Insigths-Service-Map.aspx

Com ele será possivel ver as interligações e serviços que cada servidor utiliza entre no ambiente e mapear qual serviço temos para substituir.

Entendendo o Conceito de Datacenter do Azure

Para desenhar um datacenter usando VMWare, Hyper-V ou KVM é necessário que o desenho dos hosts, rede e outros detalhes sejam feitos por especialistas no hypervisor.

O mesmo vale para Azure, precisamos entender os diferentes componentes para desenhar um datacenter com seus recursos.

Para isso, é necessário estudar, e muito.   Tambem é necessário quebrar os paradigmas de datacenter fisico e pensar em serviços.

Uma das formas de fazer isso é utilizar o Guide da própria Microsoft disponivel em https://docs.microsoft.com/en-us/azure/architecture/vdc/

Esse guia tem todas as perspectivas de um datacenter virtual, o ajudará a entender a camada de virtualização, rede, segurança, serviços e o lift and shift, ou seja a transformação para um modelo mais eficiente.

Para começar baixe a apresentação disponivel em https://aka.ms/VDC/Deck

Conclusão

Não é fácil fazer uma migração correta, mas é possivel e o resultado será muito melhor.

Ao longo do mês iremos explorar os itens que compõe o VDC e verá que é possivel fazer esse tipo de migração com recursos novos, mais eficientes e custos apropriados.

System Center 2019 e Windows Server 2019 – Upgrade in place

Como conhecido, o System Center saiu em sua nova versão, agora seguindo o mesmo conceito de Branch (Current Branch) do Windows. De agora em diante veremos as versões seguindo o numero que indica a edição:

image

A versão 2019 da suite não teve alterações em layouts ou funcionalidades principais, mas acrescenta diversos recursos novos.

Atualmente temos disponivel a nova versão 1801, que se aproxima muito do que será a versão 2019 que terá como build 1901 com data de lançamento previsto em Março.

Estes recursos podem ser visualizados no link: https://thesystemcenterblog.com/2018/09/25/whats-new-in-system-center-2019/

Upgrade do System Center Configuration Manager

O SCCM já desde a versão 2016 tem o upgrade como uma funcionalidade nativa e automática. Sempre foi muito estável e fácil de ser realizada, ficando disponivel em Administration –> Updates and Services:

Upgrade SC (10)

Após iniciado, pode-se ir pelo menu da barra superior e acompanhar toda a instalação passo a passo:

Upgrade SC (1)

Lembrando que não é possivel interagir com o upgrade após iniciado, mas em caso de se escolher deixar as features desabilitadas no menu mostrado na primeira imagem, escolha a opção Features para incluir uma das novas.

Pessoalmente sempre prefiro fazer a instalação dos upgrades sem selecionar features e depois incluir as que desejo, assim posso estudar o impacto e real necessidade de mais componentes sendo executados no servidor.

Upgrade do System Center Service Manager

Tambem simples de ser realizado, insira a midia do SCSM e ele já entrará no modo de upgrade onde você irá selecionar qual dos servidores locais está sendo atualizado. Lembrando que é importante saber a estrutura para escolher a função correta do servidor que está sendo atualizado, no meu caso o Management Server:

Upgrade SC (2)

Upgrade SC (6)

A atualização é bem tranquila, e ao final já está executando. O novo portal de auto-serviço agora oferece a experiencia HTML5 sem necessidade de componentes adicionais:

Upgrade SC (9)

Upgrade do System Center Operations Manager

A Microsoft realmente aprendeu a fazer upgrades de versão com o System Center transparentes, rapidas e eficientes. O mesmo vale para o SCOM.

Similar ao SCSM, basta incluir a midia e executar o modo de upgrade:

Upgrade SC (3)

Upgrade SC (8)

A mensagem de Warning na tela acima existe desde as versões anteriores. Como os instaladores do System Center não pedem chave, em alguns é necessário fazer a inserção da chave posteriormente.

Para inserir a chave, execute o PowerShell do SCOM e utilize o comando, lembrando que agora a chave de instalação do System Center é a mesma para toda a suite desde a versão 2012:

Set-SCOMLicense -ProductId 'xxxxx’

Upgrade do System Center Orchestrator e Virtual Machine Manager

Para fazer o upgrade do SCO tive que primeiro desinstalar o servidor. O motivo no meu caso foi a instalação de um update no meio do ano que era beta e com isso o upgrade automático não é possivel.

Nesses casos, faça a desinstalação do servidor com a opção Retain Database ativada, mesmo sendo a do SCVMM a do Orchestrator é similar:

Upgrade SC (7)

Depois de desinstalar a versão anterior, ou mesmo para um refresh, refaça a instalação com a opção de utilizar um banco de dados já existente:

Upgrade SC (4)

Upgrade SC (5)

Upgrade SC (12)

Com isso a instalação tanto do System Center Orchestrator quanto do Virtual Machine Manager finaliza com os mesmos dados existentes.

Em muitos casos, o Orchestrator e o Virtual Machine Manager para no meio da instalação com um erro genérico de banco de dados, com a mensagem: “DBSetup.exe fails with unknown error 0x800A0E7A”

Se isso acontecer no seu caso, baixe e instale o SQL Server 2012 Native Client – QFE disponivel em https://www.microsoft.com/en-us/download/details.aspx?id=50402

Upgrade do Windows Server 2019 com Serviços de System Center

Em alguns dos servidores, antes de fazer o upgrade do Windows realizei o upgrade do System Center.

Isso porque o System Center 2019 é compativel com o Windows Server 2012 R2, mas o contrário não. Isso quer dizer que é mais confiavel primeiro o upgrade dos serviços e depois do Sistema Operacional que tambem é compativel.

Upgrade SC (11)

Conclusão

O upgrade dos servidores System Center são estáveis, mas lembre-se de sempre ter um backup das bases de dados se ocorrer um problema nessas fases.

Tambem é importante lembrar das regras de ordem, em geral os Management Servers antes das outras funções.

Operations Management Suite (OMS) agora é Azure Monitoring

Já a algum tempo que o OMS é uma ferramenta que sempre abordo em clientes e eventos.

É um produto muito bom, com analises ricas e que evoluiu bastante neste ultimo ano, chegando a ser o produto que muitos acham que substituirá no futuro o System Center.

O que mudou na interface?

A interface anterior era mais simples e em um portal a parte como está no post abaixo:

http://www.marcelosincic.com.br/post/Adquirindo-e-Licenciamento-o-Azure-OMS-Operation-Management-Suite.aspx

Agora a interface é integrada no painel do Azure, permite criar novos dashboards facilmente. Alem disso é possivel acessar individualmente cada um dos monitores.

image

image

Com essa integração na interface do Azure ficou muito mais fácil e funcional.

E como ficou o licenciamento?

No post onde já havia abordado o OMS falamos sobre a aquisição que era complexa pois cada modulo fazia parte de um bundle, e cada bundle se soluções era pago separado. Havia a opção de comprar por nó ou por upload de log, mas havia limitação de soluções e modulos no modelo de pagamento por upload.

Agora ficou muito mais fácil, só existe um modo de cobrança que é por upload de dados.

Ou seja, agora você pode pagar pelo tamanho dos logs que envia, o que é bem mais prático e simples!

https://azure.microsoft.com/pt-br/blog/introducing-a-new-way-to-purchase-azure-monitoring-services/

image

Se não utiliza o Log Insights por não entender como pagar, agora ficou simples e bem mais barato!

Login
Marcelo de Moraes Sincic | Conectando os Produtos System Center para Melhor Integração
MVP: System Center Cloud and Datacenter Management, MCT, MCSE, MCITP, MCPD, MCDBA
MVP Logo

Pageviews 2019: 577846
Pageviews 2018: 4296564
Pageviews 2017: 4351543
Pageviews 2016: 3991973
Pageviews 2015: 2675433
Pageviews 2014: 2664208
Pageviews 2013: 2399409
Pageviews 2012: 3209633
Pageviews 2011: 2730038
Pageviews 2010: 1470924
Pageviews 2009: 64608

Últimos posts

Categorias

Arquivo

Tags

Conectando os Produtos System Center para Melhor Integração

Muitos que usam os produtos System Center 2012 ainda utilizam as ferramentas como nas versões 2007 e 2008, ou seja, de forma autônoma.

Assim, o Service Manager recebe incidentes manualmente quando algum tipo de alerta é gerado no Operations Manager. Os relatórios e dados de inventário (CI) precisam ser consultados no Configuration Manager.

Utilizando os conectores do Service Manager podemos integrar todos os produtos como mostra o diagrama abaixo:

image

Como pode ser visto no diagrama, é o Service Manager que faz o papel de integrador entre os diferentes produtos System Center. O Orchestrator também atua, porem por meio dos Runbooks que podem interagir com o desenho de atividades, mas já comentei em outro post http://www.marcelosincic.com.br/blog/post/Orchestrator-Integration-Packs-para-System-Center-2012.aspx

Criação de Conectores no Operations Manager

Os conectores precisam ser criados dos dois lados, inicialmente pelo Operations Manager em Administration –> Internal Connectors, como pode ser visto abaixo, onde os diversos conectores já estão criados, sendo que apenas um é criado no assistente e os outros criados automaticamente conforme o número de Management Packs:

08-02-2013 11-37-57

O primeiro passo é definir o nome do conector e quais os grupos de computadores do SCOM serão integrados:

08-02-2013 11-35-45

08-02-2013 11-35-53

No passo seguinte definimos quais são os Management Packs que serão integrados com o Service Manager, sendo que no momento de criação do conector pode-se escolher todos e fazer a manutenção após o conector já criado e testado, como será mostrado no próximo tópico:

08-02-2013 11-36-02

O ultimo passo ao criar o conector é definir critérios de filtro. Este item é mais importante que os dois acima (Computer Groups e Management Packs), pois permite definir de forma granular quais alertas irão gerar os incidentes no Service Manager. Por exemplo, apenas os erros são importantes em incidentes, assim como a prioridade e o estado do alerta no SCOM.

Também é importante notar que os incidentes no Service Manager podem ser abertos pelos estados resultantes dos Healthy Monitors do Operations Manager, o que amplia em muito o número de incidentes que serão gerados:

08-02-2013 11-36-10

Edição do Conector no Service Manager

Criado o conector no console do Operations Manager é possivel ver o mesmo conector replicado no Service Manager em Administration –> Conectors.

Se for necessário alterar como os incidentes são abertos, registrados e auto-atualizados é necessário alterar o conector pelo console do Service Manager, como mostrado na tela abaixo:

08-02-2013 11-36-28

Na tela de configuração do template definimos os critérios dos incidentes que serão sincronizados, lembrando que caso não seja configurado corretamente o conector no Service Manager, ao fechar um incidente este não será encerrado no Operations Manager e vice-versa.

No exemplo abaixo, selecionei todos os computadores pelo grupo, mas poderia ser feito um filtro pelo Management Pack, nivel de severidade, prioridade ou mesmo um campo personalizado:

08-02-2013 11-37-15

Criando Conectores de Itens (CI) no Service Manager

Note que a importação dos Management Packs tem a ver com os itens de configuração e não com os alertas definidos anteriormente.

Neste caso, o que será importado são itens, computadores e dados recolhidos dos agentes pelo Operations Manager, para formar a biblioteca de dados de configuração junto com o próprio System Center Configuration Manager.

Sendo assim, criar o conector de itens de configuração não é tão importante quanto criar o conector para os alertas, principalmente em ambientes onde o System Center Configuration Manager também foi implementado e sincronizado.

De qualquer forma, recomendo que se crie o conector de CI para que máquinas monitoradas pelo Operations Manager e que não contenham agente do Configuration Manager estejam contempladas no banco de dados do Service Manager ao abrir um chamado. Alem disso, o conector permitirá ver aplicações como sites do IIS e outros serviços do Windows pelo Service Manager.

Para criar e administrar este conector, basta definir quais os Management Packs que irão enviar dados e o agendamento para esta tarefa:

08-02-2013 11-38-52

Outros Conectores

Mais detalhes de cada um dos conectores pode ser vista no TechNet em http://technet.microsoft.com/en-us/library/hh524326.aspx

 

 

image

Para mais informações sobre o Windows Server 2012, acesse: http://clk.atdmt.com/MBL/go/425205719/direct/01/

Os comentários estão fechados
Login