Iniciativas do CCE em direção à

Nuvem Nuvem

29.3.2011

Alberto Camilli

Histórico

• 2003– Uso de storage em rede SAN –FC para serviços de correio eletrônico e backup

• 2004– Serviços de hospedagem de servidores para a comunidade USP em nosso data center: Housing, Web

Hosting e “Housting”

• 2007– Primeiras máquinas virtuais hospedando aplicações

• Col (VirtualServer Microsoft)

• Web hosting em ambiente Linux (VMware)

• Web hosting em ambiente Windows (VMware)

• 2008• 2008– Generalização no uso de maquinas virtuais para atendimento de serviços internos

– Adoção de storage virtual em rede Ethernet (iSCSI)

• 2009– GridUSP: uma abordagem em Nuvem para Grid (Xen OpenSource)

• 2010– Consolidação do sistema de correio eletrônico (Xen -> VMware)

– Janus (Xen -> Vmware)

– Univesp/Redefor (Xen Citrix)

– Multimeios IPTV (HyperV Microsoft)

• 2011– Incentivos à Hospedagem Virtual

– Restrições à hospedagem tipo Housing

– 96 máquinas virtuais (30 no correio eletrônico) em VMware e 58 em Citrix Xen (Redefor/Univesp)

GridUSP: A Scientific Cloud (2009)http://www.beliefproject.org/zero-in/zero-in-fourth-issue-emagazine/gridusp-as-a-central-

facility-to-e-science-in-brazil

Cluster Puma

• 11 nós físicos alocados em VM

Fila Flex (VMs c/várias configurações)

• 36 nós físicos (nó = 8 cores/16GB)

Filas:

•Long : 15 dias running

•Special: 7 dias running, não roda serial

•Batch: só roda serial

Um instanciador de nuvens:

OpenNebula (2009)

WS API (não fizemos)

Haizea

Instanciador de ambientes virtuaisInstanciador de ambientes virtuais

Ex. de configuração do OpenNebula

Apropriação da imagem ao ON

Criação da rede virtual “LAN”

Subindo a rede virtual “LAN”

pelo ON

Criação da máquina virtual vm01

Dentro da rede LAN

Subindo a máquina virtual vm01

pelo ON

Janus (2009-2010)

• janus.usp.br

– Sistema alocado inicialmente no cluster Puma, por

falta de máquinas onde rodar

– 8 cores default, 16 cores no pico (matrícula). – 8 cores default, 16 cores no pico (matrícula).

Alocação manual pelo OpenNebula, atráves de 1

linha de comando.

– Atualmente migrando de plataforma de cluster

para servidor adensado

Proposta levada ao Geinfo 2010

CatálogoCatálogo

HTTP

Outras nuvens (proposta)Outras nuvens (proposta)

Infraestrutura

Rede de Armazenamento

Red

N

Red

e

SA

N

Serv

ido

rSe

rvid

or

es

es

Serv

ido

rSe

rvid

or

es

es

Rede de DadosRede de

Gerenciamento

Rede de

Gerenciamento

Open Nebula

XML - RPC OCCI / EC2

Red

Net

Red

e

USP

Net

Ethernet

10 Gbps

Perfis default das VMs:•magras: 1 core, 500MB

•padrão: 2 cores, 2 GB

•gordas: 4 cores, 8 GB

Catálogo de serviços

Dificultadores para Hospedagem Virtual na USP• O usuário pede sempre a configuração máxima. Ex:

1. PPGEMSolicitado: 2 CPUs físicas , 6GB RAM, 2TB discoDisponibilizado: 2vCPUs, 2GB RAM, 4GB disco local, 300GB disco storageEm uso real: 1GB RAM (50% do disponibilizado), 1.5GB disco local (40% do disponibilizado local), 0GB (0% do disponibilizado storage) --> não está usando os 300GB do storage (22/03/2011)

2. RITU (RNP)Solicitado: 2CPUs físicas , 8GB RAM, 2TB disco (informaram que era extremamente necessário)Disponibilizado: 2vCPUs, 4GB RAM, 4GB disco local, 2TB disco storageDisponibilizado: 2vCPUs, 4GB RAM, 4GB disco local, 2TB disco storageEm uso real: 1GB RAM (25% do disponibilizado), 4GB disco local (100% do disponibilizado, pediram para aumentar para 50GB), 32GB disco storage (3% do disponibilizado)

3. Reitoria (Sharepoint)Solicitado: xCPUs, 16GB RAM, 500GB discoDisponibilizado: 2vCPUs, 4GB RAM, 160GB storageEm uso real: 0,5 GB RAM, 40 GB alocado no storage, mas, não necessariamente utilizado na máquina.

Conclusões a partir de nossa experiência:

• o usuário USP deseja customização

• nem todos precisam da máquina virtual que imaginam

• a gestão eficiente dos ambientes virtualizados é fundamental para alcançar os objetivos da Universidade (eficiência energética e racionalidade no uso de recursos de TI)

2009

(2 racks)

Virtualização bem sucedida (1)

correio eletrônico (2009-2011)

2011

(1/4 rack)30 servidores � 8 lâminas

Escalável na plataforma

Virtualização bem sucedida (2)

Redefor/Univesp (2010)

18 servidores � 4 lâminas

Escalável na plataforma

Esboço de uma Nuvem Privada:

contingência do IDC na Terremark

Ex: IDC Terremark para contingência- II

Pontos sensíveis para Nuvem: armazenamento e rede

Onde ligar a rede de armazenamento?

Virtualização de storage

Virtualização da rede

Deseja-se:�Gerenciamento unificado de todos os switches com um único

�Conexões para servidores mulithome activo-activo

�Migração automática dos perfis das portas

�Múltiplas tecnologias (Eth, FC, FCoE, etc)

Sem padronização em L2: TRILL, SPB, PBB, IRF, M-LAB ou outro?

Onde mais virtualizar ?

O que a ferramenta de Nuvem deveria

proporcionar?

– Console única de gerenciamento para rede e storage

– Configuração da Nuvem

– Escalabilidade para milhares de hosts

– Movimentação a quente– Movimentação a quente

– Manutenção sem indisponibilidade

– Possibilidade de interoperabilidade com outras ferramentas e controle na mesma console

– Otimização de desempenho para o pool de recursos

– Prover alta disponibilidade, tolerância a falhas, escalonador de recursos distribuídos

Exemplo de ferramenta de mercado

Licença por processador (chip).

Versão acadêmica vSphere: R$ 1500/processador, vCenter: 7500, mais manutenção 500

Ex: blade CCE, 32 processadores

Valores aproximados em licença para vCenter e vSphere: R$ 70 mil

Dilemas com a falta de padronização

� Gestão da rede da Nuvem - até onde podemos ou devemos ir?– Como atravessar as fronteiras da camada 3 da rede?

(TRansparent Interconnection of Lots of Links (TRILL) [IETF, L2 link state, Cisco, Brocade, HP] x Shortest Path Bridging (SPB) [IEEE, Juniper, HP, Huawei, Avaya, Alcatel] x Provider BackboneBridging (PBB) [IEEE]Juniper, HP, Huawei, Avaya, Alcatel] x Provider BackboneBridging (PBB) [IEEE]

� Comprar ou Desenvolver (ex: VMware x Citrix Server)?• Citrix VMotion vem no pacote. Usado no Redefor/Univesp

• Porém o requisito da paravirtualização inviabiliza algumas aplicações linkadas em kernel (ex: Lustre FS)

A abordagem do CCE

• Sistemas em produção: minimizar os riscos– Utilizar dispositivos, ferramentas e sistemas consolidados com

ferramentas de mercado: funcionalidade + desempenho

Foco: sistemas corporativos centrais e das Unidades. Tipicamente não elásticos.

Investimentos em recursos de gerenciamento (software).

• Sistemas experimentais: gerenciar os riscos aceitáveis– Utilizar ferramentas e sistemas de domínio público

– Desenvolver as API

– Desenvolver aplicações sobre a Nuvem e Integrar sistemas em uso

Foco: sistemas para suporte acadêmico e/ou experimentais (clusters virtuais, armazenamento em nuvem, distribuição de vídeo). Tipicamente elásticos.

Investimentos em recursos de computação (hardware).

CloudUSP – possibilidades

�Produção x Experimental

�Corporativo x Acadêmico

�Centralizado x Descentralizado

�Privado x Público x Híbrido (federações)�Privado x Público x Híbrido (federações)

“You can't always get what you want (no)

But if you try sometimes you just might find

You get what you need”

Rolling Stones