Segue minha palestra no TcheLinux Live 2021, fico a disposição para qualquer dúvida. Podem comentar, enviar e-mail que terei enorme prazer em ajudar. Abs

Neste post compartilharei um dashboard em grafana com metricas avançadas de latency/journal/queue/iops/throughput que te ajudaram a ajustar melhor as configurações do seu cluster, visto que pesquisando na internet não achei nenhum dash de ceph latência com telegraf, mas não era à toa, pois só na versão Lumiuous foi corrigido “admin socket permission” então resolvi criar do zero e compartilhar com a comunidade, explicando os principais pontos para utilizar tanto no jewel quanto no luminous.

Não irei abordar instalação do influxdb, grafana e telegraf pois tem muita coisa na internet, apenas os pontos principais para o dashboard funcionar.

Com o comando abaixo é possível verificar media latência do commit e apply do Ceph

# ceph osd perf

commit_latency(ms) apply_latency(ms)
............... ......................

Comentarei os 4 mais importantes:

A gravação do objeto em um cluster com replica de 3 gastará 6 IOs, para se concluido por conta da gravação journal(O_DIRECT) e do buffered_io para o disco efetivamente nas OSDs. Na maioria das vezes veremos mais IOs de write por conta das suboperações do ceph de replicação, diferente do read que só faz leitura na OSD primaria.

• ops - Operações nas OSDs.
• Journal_latency - Tempo que leva para gravar no journal, ou seja, tempo de ack do write para o cliente.(O_DIRECT e O_DSYNC)
• apply_latency - Tempo de latência até a transação termina, ou seja, o tempo de gravação + journal.
• commit_latency - Tempo que leva para realizar o syncfs() após a expiração do filestore_max_sync_interval, no caso a descida do journal para o disco.

As métricas acima são as que nos dão uma media de como anda a latência do nosso cluster, o dashboard abaixo irá apresentar no grafana essas informações entre outras.

Por padrão algumas métricas de subsystem do cluster Ceph já vem ativo, outras teremos que ativar no ceph.conf ou via OSDs com inject. Verifique se seu cluster está com os perfs true.

# ceph --admin-daemon /var/run/ceph/ceph-osd.26.asok  config show | grep perf
"debug_perfcounter": "0\/0",
"perf": "true",
"mutex_perf_counter": "true",
"throttler_perf_counter": "true",

Crie o arquivo abaixo e não esqueça de adicionar as tags para facilitar a seleção no grafana entre SATA e SSD ou escolha uma tag de sua preferência.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40

# cat /etc/telegraf/telegraf.d/ceph.conf
[[inputs.ceph]]
  ## This is the recommended interval to poll.  Too frequent and you will lose
  ## data points due to timeouts during rebalancing and recovery
  interval = '1m'
  tags = "storage,osd,ssd"
  ## All configuration values are optional, defaults are shown below

  ## location of ceph binary
  ceph_binary = "/usr/bin/ceph"

  ## directory in which to look for socket files
  socket_dir = "/var/run/ceph"

  ## prefix of MON and OSD socket files, used to determine socket type
  #mon_prefix = "ceph-mon"
  osd_prefix = "ceph-osd"

  ## suffix used to identify socket files
  socket_suffix = "asok"

  ## Ceph user to authenticate as, ceph will search for the corresponding keyring
  ## e.g. client.admin.keyring in /etc/ceph, or the explicit path defined in the
  ## client section of ceph.conf for example:
  ##
  ##     [client.telegraf]
  ##         keyring = /etc/ceph/client.telegraf.keyring
  ##
  ## Consult the ceph documentation for more detail on keyring generation.
  #ceph_user = "client.telegraf"

  ## Ceph configuration to use to locate the cluster
  #ceph_config = "/etc/ceph/ceph.conf"

  ## Whether to gather statistics via the admin socket
  gather_admin_socket_stats = true

  ## Whether to gather statistics via ceph commands, requires ceph_user and ceph_config
  ## to be specified
  #gather_cluster_stats = true

Será nescessario adicionar o usuario telegraf no grupo ceph para que ele possa ler os sockets do /var/run/ceph

# addgroup telegraf ceph

ATENÇÃO: Aqui está o pulo do gato, nas versões anteriores ao Ceph 12.0.3 Luminous, terá que executar o seguinte comando abaixo

# chmod  g+w /var/run/ceph/*

Esse comando contorna o problema “admin socket permission” que foi corrigido nas versões acima da 12.0.3

common: common/admin_socket: add config for admin socket permission bits (pr#11684, runsisi) https://github.com/ceph/ceph/pull/11684

Se a OSD for reiniciada a permissão se perder, se estiver abaixo da 12.0.3, recomendo adicionar a permissão no systemd após o startup da OSD. Se já estiver na versão superior basta adicionar no ceph.conf a config abaixo

admin_socket_mode 0775

Reiniciei o telegraf

systemctl restart telegraf 

Verifique se não está ocorrendo nenhum error de socket no syslog

telegraf[986875]: 2018-09-18T21:49:03Z E! error reading from socket '/var/run/ceph/ceph-osd.51.asok': error running ceph dump: exit status 22

Teste se o telegraf está coletando as metricas do seu servidor de OSD com a permissão do telegraf

# sudo -u telegraf telegraf --debug -test -config /etc/telegraf/telegraf.conf -config-directory /etc/telegraf/telegraf.d  -input-filter ceph

# sudo -u telegraf ceph --admin-daemon /var/run/ceph/ceph-osd.14.asok perf dump

Se tudo estiver ok, basta importa o dashboard para seu grafana e ser feliz! :)

Dashboard Telegraf Ceph - Latency: https://grafana.com/dashboards/7995

Plugin Utilizado: https://github.com/influxdata/telegraf/tree/master/plugins/inputs/ceph

No próximos post irei apresentar:

• Melhores práticas com Ceph - Desde o Hardware, S.O e configurações do ceph.conf para você obter melhor performance do seu cluster.

Referências de métricas:

https://access.redhat.com/documentation/en-us/red_hat_ceph_storage/3/html/administration_guide/performance_counters

Recentemente eu tive um problema de badblock em um dos discos que gerou uma inconsistent na PG e o cluster não conseguiu se resolver automaticamente, mesmo tirando o disco defeituoso do cluster e parando a OSD associada.

As soluções abaixo me ajudaram a resolver meu problema que se estendeu por alguns dias. Caso tenha suporte recomendo abrir um chamado ou faça por sua conta e risco.

A solução 1 resolver a maioria dos casos e no meu caso não houver impacto nem downtime.

Problema ocorreu no Ubuntu 16.4 com Jewel utilizando FileStore replica de 3.

Antes de iniciar recomendo a leitura do meu post “Ceph Scrubbing” será fundamental você entender esse cara antes de começar.

1 - Buscando pgs inconsistente no nosso caso “5.163”

# ceph health detail  | grep inconsistent
HEALTH_ERR 
pg 5.163 is active+remapped+inconsistent+wait_backfill, acting [26,45,135]

Podemos ver que apresentou também em quais OSDs estão essas pgs [26,45,135] execute o comando abaixo para descobrir em quais servidores estão as OSDs

root@serv-117:/home/bruno.carvalho# ceph osd find 26
{   
    "osd": 16,
    "ip": "10.0.0.14:6842\/21992",
    "crush_location": {
        "host": "stor-121",
        "rack": "sata",
        "root": "default"
    }
}
root@serv-117:/home/bruno.carvalho# ceph osd find 45
{
    "osd": 91,
    "ip": "10.0.0.15:6814\/8362",
    "crush_location": {
        "host": "stor-122",
        "rack": "sata",
        "root": "default"
    }
}
root@serv-117:/home/bruno.carvalho# ceph osd find 135
{
    "osd": 30,
    "ip": "10.0.0.17:6812\/10485",
    "crush_location": {
        "host": "stor-124",
        "rack": "sata",
        "root": "default"
    }
}

2 - Logue no servidor da OSD primaria e busque o objeto problemático, se objeto problemático estiver na primaria não esqueça de descer com primary-affinity.()

# grep -Hn 'ERR' /var/log/ceph/ceph-osd.26.log (apresentar uma tripa de erro, o importante será o nome do objeto )
..... log [ERR] : 5.163 .... 
udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4
.....

No Monitor podemos buscar com o comando abaixo (apresenta um json grande, porem o importante é o nome do objeto, algo parecido com nome do comando acima.)

# rados list-inconsistent-obj 5.163--format=json-pretty

Se nescessário jogue a OSD primário para outra OSD.

# ceph osd primary-affinity 26 0

3 - Logue nos servidores das 3 OSDs, busque o arquivo e verifique o md5 do objeto, seu tamanho e identifique o que está diferente entre os 3, no caso o objeto diferente será o que você irar remover para mandar o cluster se recuperar.

# find /var/lib/ceph/osd/ceph-26/current/5.163_head/ -name '*00000000000059d2*' -ls
...
/var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4
# md5sum /var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4\
d12a1f042f2a98a79943c990d3a5b2c8  /var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4

4 - Set noout no cluster

# ceph osd set noout

5 - Pare a OSD

# systemctl stop ceph-osd@26

6 - Execute o flush do journal

# ceph-osd -i 26 --flush-journal
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
SG_IO: bad/missing sense data, sb[]:  70 00 05 00 00 00 00 0a 00 00 00 00 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
2018-08-23 18:31:57.691076 7f69269888c0 -1 flushed journal /var/lib/ceph/osd/ceph-26/journal for object store /var/lib/ceph/osd/ceph-26

7 - Remova o Objecto com problema

# rm  -rf /var/lib/ceph/osd/ceph-26/current/5.163_head/rbd\\udata.3b2ab5c0fdd3f.00000000000059d2__head_892078F9__4

8 - Corrigindo permissão da OSD

# chown ceph:ceph -R /var/lib/ceph/osd/ceph-26/current/omap/

9 - Subindo OSD

# systemctl start ceph-osd@26

10 - Tira o noout no cluster e aguarde o cluster ficar com apenas a pg inconsistent

# ceph osd unset noout

11 - Vamos agora executar um repair para corrigir o problema.

# ceph pg repair 5.163

Agora veja o log da OSD primaria.

# tail -f /var/log/ceph/ceph-osd.26.log

2018-08-23 18:33:30.568207 7fc1ee195700 -1 log_channel(cluster) log [ERR] : 5.163 shard 26 missing 5:9f1e0491:::rbd_data.3b2ab5c0fdd3f.00000000000059d2:head
2018-08-23 18:33:30.568212 7fc1ee195700  0 log_channel(cluster) do_log log to syslog
2018-08-23 18:33:36.274075 7fc1ee195700 -1 log_channel(cluster) log [ERR] : 5.163 repair 1 missing, 0 inconsistent objects
2018-08-23 18:33:36.274079 7fc1ee195700  0 log_channel(cluster) do_log log to syslog    
2018-08-23 18:33:36.274142 7fc1ee195700 -1 log_channel(cluster) log [ERR] : 5.163 repair 1 errors, 1 fixed
2018-08-23 18:33:36.274144 7fc1ee195700  0 log_channel(cluster) do_log log to syslog

No log acima podemos ver “log [ERR] : 5.163 repair 1 errors, 1 fixed” isso mostra que ele encontrou o objecto que faltava e corrigiu criando novamente a replica.

Solução 2

Identificar e remover o objeto problemático na OSD excluindo com ceph-object-tools executando com deep-scrub

Com o objeto problemático já identificado, execute os procedimentos: 4, 5 e 6 após sigar os procedimentos abaixo

1 - Com a OSD down localize o objeto

# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-26 --journal /var/lib/ceph/osd/ceph-26/journal --pgid 5.163 --op list | grep rbd_data.3b2ab5c0fdd3f.00000000000059d2
["5.163",{"oid":"rbd_data.3b2ab5c0fdd3f.00000000000059d2","key":"","snapid":-2,"hash":3828189539,"max":0,"pool":5,"namespace":"","max":0}]

2 - Removendo Objeto.

# ceph-objectstore-tool --data-path /var/lib/ceph/osd/ceph-26 --journal /var/lib/ceph/osd/ceph-26/journal --pgid 5.163 '{"oid":"rbd_data.3b2ab5c0fdd3f.00000000000059d","key":"","snapid":-2,"hash":3828189539,"max":0,"pool":5,"namespace":"","max":0}' remove
remove #5:c691b427:::rbd_data.3b2ab5c0fdd3f.00000000000059d2:head#

3 - Corrigir permissão

# chown -R ceph:ceph /var/lib/ceph/osd/ceph-135/current/omap/

4 - Iniciar OSD

# systemctl start ceph-osd@26

5 - Execute o deep-scrub na pg (Veja artigo do “Ceph Scrubbing”, para execução com espaço de tempo menor)

# ceph pg deep-scrub 5.163

O deep-scrub no CEPH é um processo que passa em todas OSDs para verificar inconsitencia dos dados e corrigir eventuais problemas, podemos comparar ao fsck. Dependendo das configurações do seu Cluster o deep-scrub não executará imediatamente, verifique no log da OSD primaria ou execute o seguinte comando query pg e veja data da ultima vez que ele passou.

Se o deep-scrub não for executado, verifique as configurações de osd_scrub_max_interval, também é importante verificar o osd_scrub_load_threshold, pois se sua CPU estiver e um certo limite o deep-scrub não rodará.

Leia mais sobre: “Ceph Scrubbing”

6 - Query pg

#  ceph pg 5.163 query 
..................
        "last_deep_scrub_stamp": "2018-08-23 15:48:42.107928",
..................   

Também podemos verificar logo no final do comando query o deep-scrub sendo executado na PG.

"scrub": {
            "scrubber.epoch_start": "57000",
            "scrubber.active": 1,
            "scrubber.state": "WAIT_REPLICAS",
            "scrubber.start": "5:578cfc17:::rbd_data.57e3dd6b7d297f.000000000000b063:0",
            "scrubber.end": "5:578cff8c:::rbd_data.552a0c53cb890c.00000000000046aa:0",
            "scrubber.subset_last_update": "58460'37642760",
            "scrubber.deep": true,
            "scrubber.seed": 4294967295,
            "scrubber.waiting_on": 1,
            "scrubber.waiting_on_whom": [
                "48"

Após o termino do deep-scrub provavelmente sua pg já estará OK.

No próximo post irei apresentar:

- Métricas de Latência no Ceph

Referência: http://lists.ceph.com/pipermail/ceph-users-ceph.com/

Olá turmadaaa, um pouco sumido, mas estou de volta com grandes novidades. A pouco mais de 2 anos realizei a implantação de 4 Cluster Ceph com Juju e MaaS na america latina que hoje tem quase 8 Petabyte raw, e quanto mais o cluster cresce, mais ajustes e problemas diferentes aparecem.

Recentemente encontrei um bug relacionado a recuperação de “Placement groups(PGs)” dentro do Jewel. O Ceph não estava conseguindo resolver a inconsistência de uma PG, mesmo executando o “ceph repair” e forçando a passagem do Scrubbing. Pelo que notei nos últimos lançamentos do CEPH tem alguns bug fix sobre o assunto.

Bem este será o primeiro de alguns posts mais avançado que irei falar de como resolver manualmente uma pg inconsistente, mas neste momento vamos entender melhor o Scrubbing no Ceph

Podemos comparar o Scrubbing do Ceph com o fsck para o armazenamento de objetos dentro do Cluster. Ao executar “ceph -s” nas ultimas linhas veremos as “placement groups(PGs)” que estão como “active+clean”, que significa que estão oks.

Para cada placement groups(PGs) o Ceph gera um catálogo de todos os objetos e compara cada objeto primário e suas réplicas garantindo assim que nenhum objeto esteja ausente ou seja incompatível. Muitas vezes vamos achar a seguinte informação “1 active+clean+inconsistent” isso nos mostrar que alguma replicar dentro do cluster está inconsistente. Como o Ceph realizado seu auto reconvery esse problema é resolvido automaticamente na passagem do scrub, porem recentemente percebi que isso não é uma verdade absoluta se você não tiver um ambiente bem configurado.

A passagem do Scrubbing é penosa para o cluster e muitas vezes só passará quando o sistema estiver com uma carga menor ou se as configurações forem alteradas via inject nas “OSDs”. Veja as 3 formas que podemos verificar as configurações no cluster e como podemos alterar a quente e força uma passagem imediata do scrub.

Verificando configurações no Ceph:

Apresenta apenas as configurações default do ceph

# ceph --show-config | grep osd_scrub_load_threshold

Apresenta a configuração permanente do ceph.conf

# ceph -n osd.X --show-config | grep osd_scrub_load_threshold

Apresentar a configuração atual

# ceph --admin-daemon /var/run/ceph/ceph-osd.21.asok config show | grep osd_scrub_load_threshold

Alterando Configuração a quente

# ceph tell osd.X injectargs '--osd_scrub_load_threshold 0.5' 

O Scrubbing é muito importante para manter a integridade dos dados, mas poderá reduzir o desempenho do seu cluster, como “requests are blocked” se não for realizado ajustes nas configurações baseado na carga do seu cluster.

Existe dois tipos de Scrubbing, um e o “Light scrubbing”, ele verifica o tamanho e os atributos do objeto e por default passa todos os dias e não sobrecarrega tanto o cluster. O “deep-scrubbing” e uma limpeza mais profunda, lê os dados e usa somas de verificação para garantir a integridade, esse Scrubbing passa no decorrer da semana e gera uma carga maior no cluster. Como o “ceph -s“ conseguimos verificar em quantas “PGs” está sendo executado scrubbing no momento.

26 active+clean+scrubbing+deep 7 active+clean+scrubbing

Executando o comando abaixo, você consegue ver quando passou o último scrub/deep-scrub na PG

# Ceph osd PG_ID query 
..................
            "last_deep_scrub_stamp": "2018-08-23 15:48:42.107928",
..................   

Algumas configurações que devemos nos atentar para ajustar:

• osd_scrub_min_interval
• osd_scrub_max_interval
• osd_scrub_load_threshold
• osd_max_scrubs
• osd_deep_scrub_interval
• osd_scrub_interval_randomize_ratio
• osd_scrub_during_recovery

Os Scrubbing começam após osd_scrub_min_interval desda ultima passagem, isso só ocorre se a CPU estiver abaixo do osd_scrub_load_threshold ou após osd_scrub_max_interval mesmo se o sistema estiver sobrecarregado.

Podemos também configurar um intervalo na madrugada para o Scrubbing passar osd_scrub_begin_hour/osd_scrub_end_hour. Com lançamento do Mimic, temos mais duas opções de intervalos osd_scrub_begin_week_day/osd_scrub_end_week_day

Quando executamos um ceph pg repair, ou um ceph pg deep-scrub ele não irá executar imediatamente e sim enviará um pedido a pg “instructing pg ID on osd.X to repair” porem precisa satisfazer as regras configuradas, veja a nota da documentação oficial abaixo.

Nota: “Ceph will not scrub when the system load (as defined by getloadavg() / number of onlinecpus) is higher than this number. Default is 0.5.”

A passagem deep-scrub não necessariamente depende do load_threshold, veja a nota abaixo.

Nota: “The interval for “deep” scrubbing (fully reading all data). The osd scrub load threshold does not affect this setting.”

Atenção as frags noscrub e nodeep-scrub definida no cluster e nas pools, caso esteja setada o scrub não será executado.

Creio que com essas informações já conseguimos manipular melhor os Scrubbing no cluster, que e essencial para a consistência das “Placement groups(PGs)” e da performance do cluster. Nos próximos posts vamos entrar mais a fundo na manipulação manual do objeto e na sua recuperação.

Caso tenha alguma dúvida sobre o funcionamento do Ceph não deixa de assitir meu Webinar que postei aqui no Blog Explorando o Ceph Como tiveram várias dúvidas sobre o Webinar, lançarei uma série de artigos mais básicos com informações essencias para você ir “Explorando o Ceph”.

Nos próximo posts irei apresentar:

- Resolvendo PGs inconsistent no CEPH manualmente

Referência: http://docs.ceph.com/docs/master/rados/configuration/osd-config-ref/

A Internet das Coisas e a Terceira Plataforma Computacional estão levando as pessoas e as máquinas a gerarem milhões de dados digitais a cada instante. O volume de informações criadas no mundo, a médio e longo prazo, é infinito. Pesquisa da IBM mostra que, até 2020, o volume de dados previsto é de 40 zetabytes, ou seja, haverá quatro vezes mais dados digitais do que todos os grãos de areia existentes no planeta. As máquinas irão gerar 42% de todo volume de dados e haverá mais de 200 bilhões de dispositivos conectados no mundo.

O crescimento desenfreado de dados e as constantes mudanças exige das empresas respostas rápidas para os negócios. A expansão dos dispositivos móveis aumentou o uso das redes sociais e também de dados. As companhias precisam de tecnologias para tratar dados com estratégias de Big Data e gerar mais serviços online para o mundo conectado.

Atualmente as empresas precisam ter serviços disponíveis 24 horas, a Cloud Computing abraça todas as aplicações criadas para abastecer o mundo conectado, tanto para o mercado corporativo quando para atender o consumidor final. Para que isso gere menos custo e valor para empresas precisamos de um mundo com soluções hiperconvergentes, e sem um storage eficiente e escalável baseado em Software Defined isso se tornaria inviável para muitas empresas e startups.

No Webinar “Explorando Ceph” que será realizado pela TIVIT na próxima quarta-feira dia 4, falarei um pouco mais sobre o storage que está revolucionando o mercado de Software Defined, será totalmente gratuito e online. Inscreva-se: Aqui

GRAVAÇÃO:

Na última Quarta-feira(25/10) rolou o primeiro Ceph Day SP e o primeiro na América Latina organizado e realizado pelo nosso Manager Comunity Leonado Vaz e nosso amigo da Savant Marcos Sungaila, além de grandes patrocinadores como RedHat, Canonical, Suse entre outros…

Para quem não teve a oportunidade de estar presente perdeu um grande dia. Discutimos sobre a nova versão do Ceph, custos x performance, implementações, cases e principalmente o futuro do SDS

A chegada da nova versão Luminous LTS que já é uma realidade, virou um divisor de águas no mundo do Software Define Storage(SDS) com várias melhorias como o novo backend BlueStorage que leva o Ceph a um nível de performance 2x mais rápido eliminando a camada do filesystem, além de grandes melhorias em toda sua estrutura.

Precisando de baixa latência e alta performance? O Ceph te entrega, tivemos uma palestra da Intel, uma das grandes colaboradoras do código, falando sobre Ceph com All-Flash.

SSDs to Build High-Performance Cloud Storage Solutions

Para os amantes do Zabbix como eu, o novo serviço de gerenciamento do Ceph(ceph-mgr) foi ampliado com vários módulos python, um deles exporta o status geral do cluster para o Zabbix habilitando o modulo no Ceph e configurando o template no zabbix.

1
2

$ ceph zabbix config-set zabbix_host zabbix-server.local
$ ceph zabbix config-set identifier ceph.local

Para os amantes da interface GUI. Agora será possível ter um dashboard no Ceph de forma simples.

1

$ ceph mgr module enable dashboard

Acesse http://you_active_mgr_host:7000/

Outra grande novidade, agora já é possível fazer Erasure Coding tanto em RBD quanto em CephFS, que antes só era possível com object. Na mudança para o BlueStorage será possível suporta compressão de dados, trazendo mais economia no armazenamento.

E tem muito mais vindo por ai! Eu particularmente estou ansioso para o tão esperado QoS que está por vir na próxima versão ou dedup que será excelente para galera de backup. Aguardem que isso será só o começo da evolução que o Ceph vem trazendo para o mundo do Software Define Storage.

Referências:

http://ceph.com/releases/v12-2-0-luminous-released/

http://ceph.com/community/new-luminous-dashboard/

http://ceph.com/community/new-luminous-zabbix/

Que tal gerenciar seus Bare Metal com automação e eficiência? Te apresento o Metal as a Service (MaaS) uma ferramenta fantástica desenvolvida em Python pela Canonical que trás vários benefícios para gerenciar seus racks de Bare Metal e neste artigo irei falar um pouco das suas funções, instalação e configuração.

Segue abaixo algumas features do MaaS stable(2.2):

• Suporte para Bare Metal (ARM,Intel), KVM, VMWARE
• Provisiona com Ubuntu, RHEL, CENTOS, SLES, OpenSUSE, Windows
• Divide recursos por zonas Bare Metal/VM
• IPAM coleção de Subnets IPV4/IPV6, VLAN tagging, DNS, proxy, NTP
• REST API intregraçao com ferramentas de Devops Juju, Chef, Ansible, Puppet
• Descobre automaticamente ativos de redes, VLAN, Subnets etc..
• Enlist automático por PXE
• Interface GUI e CLI para Ligar/Desligar, comissionar, implantar, teste de hardware, modo de manutenção e recuperação de S.O
• Composição Dinâmica de Hardware por meio de POD Suporta Intel Rack Scale Design (RSD) e Virsh(KVM)
• Configuração de Rede IP,VLAN,BOND,BRIDGE layout de disco Bcache, RAID, LVM

O MaaS foi desenvolvido para ambientes em escala Bare Metal, mais também é possível gerenciar VM com Virsh(KVM). Suporta as principais BMCs e controladores de chassi do mercado como Dell, IBM, HP, Lenovo, Huawei e Open Compute Project, está sendo utilizado por grandes plays do mercado como Microsoft, Nec, Verizon, At&t, NTT atualmente sendo considerado uma das melhores ferramentas open source para gerenciamento de Bare Metal.

Como funciona

O MaaS possui uma arquitetura em camadas com um banco de dados postgresql usado na ‘Region Controller (regiond)’ que lida com as solicitações. Já o Distributed Rack Controllers (rackd) fornecem serviços para cada rack.

Region controller(regiond):

• REST API server (TCP port 5240)
• PostgreSQL database
• DNS
• caching HTTP proxy
• Web GUI

Rack Controller (rackd) fornece DHCP, IPMI, PXE, TFTP e outros serviços locais. Os rackd armazenam itens como imagens de instalação do S.O no nível do rack para melhor desempenho, mas não mantenham nenhum estado além das credenciais para falar com o Region Controller.

Rack controller(rackd):

• DHCP
• TFTP
• HTTP (para images)
• iSCSI
• Power Management

Tanto o regiond como o rackd podem ser escalados e configurados para alta disponibilidade.

Instalando o MaaS

Como podemos ver na arquitetura acima, em cada rack de servidor Bare Metal poderiamos ter um daemon chamado rackd que falaria via API com o regiond, isso e uma boa pratica para arquitetura de rede Layer 3 spine e leaf, mas neste exemplo vamos instalar tanto o regiond como o rackd em um unico servidor.

Adicionando repositorio e instalando o MaaS

1
2

# apt-add-repository -yu ppa:maas/stable
# apt install maas

Após instalação precisamos criar um usurário administrativo.

1

# maas createadmin 

Depois da criação vamos acessar o painel via browser

Acesse a URL:http://$API_HOST:5240/MAAS

Entre com login e senha criado no passo anterior

No primeiro login será apresentado uma tela de configuração, altere o nome da sua região se achar necessário e neste primeiro momento deixe como padrão os outros valores

Agora vamos verificar quais serviços estão ativos, no painel click em “Nodes” selecione a aba “Controller” selecione o servidor da sua controller depois click na aba “Services”.

Veja se sua img está sincronizada Click na Aba “Images”

• Ativando DHCP

Vá para a aba “Subnets” e selecione a untagged VLAN/subnet para a qual você deseja habilitar o DHCP, e no botão “Take action” selecione “Provide DHCP”.

• Defina o controlador de rack que gerenciará o DHCP.
• Selecione a subrede para criar o intervalo dinâmico DHCP.
• Preencha os detalhes para o intervalo dinâmico.

Após ativar o DHCP, podemos inciar os bare mental na rede configurada que automaticamente ela realizará o boot via PXE e iniciará o processo de enlist, assim aparecendo no menu “Node” do painel MaaS, abaixo veja como funciona o ciclo de vida do seu Bare Metal/VM dentro do MaaS.

Obs: para o MaaS conseguir Ligar e Desligar os servidores via IPMI será necessário um interface que chegue na rede da IDRAC e/ou ILO

Entenda o Lifecycle do MaaS

Cada máquina (“nó”) gerenciada pelo MAAS passa por um ciclo de vida desde o alistamento até o comissionamento quando o nó será inventariado e iremos poder configurar elementos específicos do hardware. No ciclo também é possível alocamos um servidor para um usuário, realizar o deployer, e finalmente liberar de volta para um pool ou deletar por completo.

Qualquer dúvida comentem aííí, até a proxima!!!!

Referências:

https://maas.io/

https://docs.ubuntu.com/maas/

Segue minha palestra no OpenStack Day SP 2017. Como a apresentação ficou corrida por conta do tempo e o ultimo slide de hands on não foi apresentado por problemas da internet local, fico a disposição para qualquer dúvida. Podem comentar, enviar e-mail que terei enorme prazer em ajudar. Abs

O que é o Juju?

Juju é uma ferramenta open source de modelagem de aplicações desenvolvida em Go pela Canonical a mesma empresa que desenvolve o Linux Ubuntu.

Com Juju é possível implementar, configurar, gerenciar, manter e dimensionar aplicações em nuvens públicas e privadas de uma forma rápida e eficiente bem como servidores físicos, OpenStack e contêineres. O Juju pode ser usado tanto em linha de comando ou através de uma interface GUI

Como é feito a “Mágica”:

A partir dos charmes é possível realizar a criação de toda uma infraestrutura no nivel de configuração da maquina virtual, instalação e configuração das aplicações, interligações de dependências, tanto na AWS, Google, Azure, OpenStack entre outras nuvem suportadas ou diretamente no Bare-Metal.

Mas que desgraça é esse Charme?

O charme define tudo o que você conhece de forma colaborativa sobre a implantação da aplicação. Tudo o que você precisa fazer é usar qualquer charme disponível (ou escrever o seu próprio), e a aplicação correspondente será implantada em segundos, em qualquer nuvem, servidor físico ou máquina virtual.

O Charme nada mais é do que um receita de instalação e configuração com gerenciamento de dependencias e interligações nescessárias para sua aplicação funcionar em uma nuvem ou em um bare-metal.

Juju então é igual ao Chef, Puppet, Ansible e cia?

Não! O Juju orquestra e escala aplicações em nuvens, ele está uma camada acima dos gereciadores de configurações, mas podemos usar todos juntos perfeitamente.

O puppet, Chef e Ansible são ótimas ferramentas para escrever arquivos de configuração. Por trabalhar uma camada acima, o Juju concentra-se nas operações de longo prazo necessárias para manter esse software em execução ao longo do tempo, independentemente da máquina na qual ele está sendo executado. O charme do Juju para um aplicativo inclui (entre outras coisas) toda a lógica para escrever arquivos de configuração para as aplicações, essa lógica em si pode ser escrita em qualquer linguagem ou ferramenta que o desenvolvedor do charme preferi.

É comum que as pessoas comecem a criar um charme juntando Puppet ou Chef ou outros scripts que eles atualmente usam para automatizar a configuração do ambiente. Se o charme vai estar escrevendo e atualizando a configuração para o aplicativo, e já existem ferramentas para abstrair esse arquivo de configuração na sua linguagem preferida (Puppet,Ansible, etc…), então use isso no charme!

Como podemos ver o Juju consegue reunir várias ferramentas de automação, deixando você livre para criar seus charme com suas receitas e ferramentas favoritas, ainda melhor, dois charmes diferentes de diferentes equipes que usam ferramentas diferentes trabalharão felizes juntos para implantar uma solução.

Veja como é fácil instalar o Juju no Ubuntu Xenial

Para fins de teste vamos instalar o juju com o LXD, que no caso poderia ser uma nuvem ou um bare-metal

$ sudo apt install lxd zfsutils-linux

Para usar o LXD, seu usuário deve ser um membro do grupo lxd, verifique com o comando abaixo provavelmente já vai estar.

$ groups

Ao executar o comando abaixo, aceite todas respostas padrão nas configurações iniciais do LXD, ou mude caso achar melhor.

$ sudo lxd init 

LXD agora está basicamente configurado para funcionar com Juju.

Instalando JUJU:

$ sudo add-apt-repository --update ppa:juju/stable
$ sudo apt install juju

Tanto para LXD, Bare-Metal ou nuvem será necessário a criação de um controle para gerenciar.

# juju bootstrap localhost lxd-test 

Isso pode demorar alguns minutos, pois o LXD deve baixar uma imagem do linux.

Uma vez concluído o processo, veja se o controlador lxd-test foi criado com o comando abaixo:

# juju controllers 

O comando a seguir mostra o controlador, modelo e o usuário atualmente ativo:

#  juju whoami 

Implantando um aplicativo com Juju.

O comando abaixo vai até o Juju store pega um charme pronto chamado mediawiki-single e manda instalar no ambiente LXD que configuramos no inicio.

# juju deploy cs:bundle/mediawiki-single 

Após este comando, podemos verificando sua implementação:

# juju status

Comando de acesso ao ambiente criado

# juju ssh id_machine

Acesso GUI, o comando abaixo exibirá a URL de acesso a interface web do Juju.

# juju gui

Pegando a senha da controladora criada para logar no Juju Gui.

# juju show-controller --show-password

Mais comandos do Juju.

# juju help commands

Caso não queira realizar a instalação, a canonical disponibilizou um demo da sua interface GUI: https://demo.jujucharms.com/

Nos próximos posts irei apresentar:

- Juju com Cloud OpenStack

- MaaS para integração do Juju com Bare-Metal

-Deployando Ceph com Juju.

Referências

https://jujucharms.com/docs/stable/

Depois de 4 anos utilizando XenServer, chegou a hora de dá um até breve. Atualmente estou migrando alguns ambientes XenServer para Ovirt/KVM pela sua constante evolução e integração com o projeto Openstack que vem crescendo muito no cenário opensource.

Primeiro passo será exporta sua VM pelo XenCenter ou pelo seu node console conforme o comando abaixo.

# xe vm-export vm=<Name of VM> filename=<Name of file ending in ".xva">

Será gerado uma imagem com extensão .xva, jogue sua imagem exportada para seu node ovirt.

Desempacotando VM.

# tar -xvf vm.xva

No meu ambiente foi criado um diretório chamado Ref:10/

Baixe o script de migração (https://github.com/hswayne77/xenserverz_to_xen)

# wget wget https://raw.githubusercontent.com/hswayne77/xenserver_to_xen/master/xenmigrate_new.py

Execute os comandos para iniciar a migração da imagem.

# python xenmigrate.py -c Ref\:10/ vm.img

enmigrate 0.7.4 — 2011.09.13
(c)2011 Jolokia Networks and Mark Pace — jolokianetworks.com

convert ref dir : ./Ref:10/
to raw file : vm.img
last file : 20484
disk image size : 20 GB

RW notification every: 1.0GB
Converting: 1.0GBrw 2.0GBrw 3.0GBrw 4.0GBrw 5.0GBrw 6.0GBrw 7.0GBrw 8.0GBrw 9.0GBrw 10.0GBrw 11.0GBrw 12.0GBrw 13.0GBrw 14.0GBrw 15.0GBrw 16.0GBrw 17.0GBrw 18.0GBrw 19.0GBrw 20.0GBrw
Successful convert

Criando Domain Storage Export no Ovirt

Acesse no browse seu Ovirt Engine vá para:

Sistema -> Data Centers -> Default -> Storage -> Novo Domain

Crie um novo Dominio “Export” conforme a imagem abaixo.

Baixe a última versão do projeto “import-to-ovirt.pl” no seguinte link http://git.annexia.org/?p=import-to-ovirt.git

Instale as dependências

# yum install perl-XML-Writer perl-Sys-Guestfs

Agora vamos importa a vm.img para o Domain Export que criamos utilizando o import-to-ovirt.pl

# export LIBGUESTFS_BACKEND=direct
# ./import-to-ovirt.pl vm.img node1.supcom:/storage/export

Pode ser utilizado com imagem .qcow2

Verifique se tudo ocorreu bem com a criação do OVF

[root@node1 storage]# ls /storage/export/ad5e39a2-24d4-4a51-ac74-cfdf843c5f94/master/vms/88397ea1-196e-4aeb-8a57-29cff914caab/88397ea1-196e-4aeb-8a57-29cff914caab.ovf

Disponbilizando a VM no Ovirt Engine

Sistema -> Data Centers -> Default -> Cluster -> Default - > MVS -> Importar”:

Selecione o Export Domain criado, click em Carregar, Seleciona a VM, click na seta central, depois Próximo.

Click OK e aguarde a VM ser importada.

Após a importação será necessário realizar algumas alterações no momento da inicialização da VM:

• Pressione “e” na inicialização do grub remova o “console=hvc0” e digite CTRL + X

Após a inicialização

• Remova o “console=hvc0” /etc/default/grub e execute:

    # update-grub
  

• Verifique se seu fstab está correto e não tenha entradas xvda

• Verifique sua network os uuid e MAC serão diferentes.

• Edite o /etc/inittab comente a linha “co:2345:respawn:/sbin/getty … ”:

A vm migrada estava com Debian 7 e a migração foi executada com sucesso seguindo os procedimentos acima

Referências:

https://gfnork.de/blog/how-to-import-qcow2-images-to-ovirt/

https://rwmj.wordpress.com/2015/09/18/importing-kvm-guests-to-ovirt-or-rhev/

http://blog.zwiegnet.com/linux-server/export-vm-command-line-xenserver-6/

https://wiki.debian.org/HowToMigrateBackAndForthBetweenXenAndKvm

Olá pessoal, estou distribuindo este Ebook gratuito produzido pela Opus sobre Computação em Nuvem que achei muito bacana, espero que ajudem a entender um pouco mais sobre o universo Cloud Computing.

Abs

Link para Download…