Infraestrutura de TIC do IFSC câmpus São José

A CTIC atualmente administra em sua infraestrutura:

Segurança e disponibilidade

Há redundância ativa no firewall da câmpus, assim como no core switch da rede (modo ativo-passivo). A figura a seguir ilustra isto:

Redundancias

A rede está configurada na forma de anel no seu core, com redundância de caminho e de links (LACP). Os racks de borda estão conectados com redundância de link aos racks centrais. A rede é segmentada em VLANs (acesso restrito ao câmpus São José) e atribuída a política de acessos entre as redes virtuais por ALCs, como por exemplo bloqueios de propagação de DHCP indevido. Além disso, o STP está configurado em toda a rede (ativos gerenciáveis).

Rede em anel

Firewall PFSense com alta disponibilidade

A solução de firewall adotada é o de redundância ativa no nosso firewall usando servidores físicos distintos.

Essa demanda foi baseada no seguinte questionamento: “E se/quando nosso firewall Cisco ASA queimar/dar problema?”. Dentro do IFSC alguns câmpus já utilizavam o PFSense como firewall e com excelentes resultados. Com isso, primeiramente foi substituído o firewall original para o PFSense para implantar alta disponibilidade. Segue a descrição de hardware dos dois servidores (ambos foram doados pela reitoria por estarem obsoletos):

Foi feito o registro em vídeo de um teste de queda do master firewall:

-Registro em Vídeo do teste

CARP Status - Firewall pfSense mestre e escravo

PFsense HA

Infraestrutura do Data Center

Possuímos uma infraestrutura hiperconvergente (HCI), utilizando soluções definidas por software (Software Defined - SD), onde armazenamento, processamento e rede compartilham o mesmo hardware de arquitetura amd64 padrão da indústria. Com isso alcançamos uma maior eficiência e agilidade na gestão dos recursos de TIC. A figura abaixo apresenta uma visão global da nossa infraestrutura :

Desenho da Infra de Serviços

Cada máquina física possui discos que fazem parte do cluster de armazenamento distribuído realizado pela ferramenta Ceph. As mesmas máquinas físicas fazem parte de um cluster de virtualização por meio da ferramenta Proxmox, possibilitando alta disponibilidade de máquinas virtuais, migração a quente, entre outros. Os discos utilizados pelas VMs são providos pelo cluster de armazenamento, mais especificamente um dispositivo de bloco do Ceph. Fazemos backups completos semanais das VMs no nosso storage diretamente pelo serviço provido pelo Proxmox.

Cluster de armazenamento: Ceph

É utilizada a implementação de Ceph integrada do Proxmox. O CRUSH map foi configurado de modo a implementar um domínio de falha com o agrupamento de servidores do tipo blade que fazem parte do mesmo chassi. Assim, é garantido que as réplicas de dados não fiquem todas no mesmo domínio de falha, e caso ocorra problema em alguma blade (os nos seus discos mapeados do storage) não haverá perda de dados ou indisponibilidade dos serviços.

CRUSH Map e Domínio de Falhas

Cluster de Virtualização: Proxmox

O cluster de virtualização foi criado a partir de máquinas com o Proxmox, sendo esse instalado seguindo a documentação de cluster do Proxmox.

Proxmox

A figura a seguir representa um exemplo da configuração de rede de uma máquina para fazer parte do cluster, com destaque para a agregação de enlace combinada com as várias VLANs (organizadas por tipo de serviço).

Example Network Proxmox Node

Os recursos (CPU, Memória e Armazenamento) são agrupados no cluster de virtualização conforme ilustrado a seguir:

Sumário

O armazenamento utilizado pelo cluster de virtualização (discos de VM, snapshots, ISOs etc.) é fornecido pelo Cluster de armazenamento Ceph. A figura a seguir ilustra os tipos de storage: sistema de arquivos cephfs (CephFS) e dispositivos de blocos Storage_Ceph (RBD) disponíveis para uso.

Storage

O “storage” Backup_NFS é um armazenamento do tipo NFS, provido por uma das máquinas conectada ao nosso storage (físico), onde são realizados os full backups das VMs semanalmente.

O cluster possui a configuração para fornecer alta disponibilidade nas VMs:

HA’

Nuvem privada: Kubernetes + Rancher

Um conjunto de máquinas virtuais compõe uma nuvem de contêineres, onde o Kubernetes é usado como o orquestrador. O gerenciamento do cluster Kubernetes, em especial a parte de autenticação e autorização, é realizado pelo Rancher. A seguir uma tela da interface do Rancher.

Rancher

As VMs que fazem parte do cluster são criadas a partir de um modelo de VM configurado com cloud init. Os requisitos de configuração e dependências são aplicados nas VMs a partir do Ansible. Já em relação a nuvem é utilizado o RKE para fazer a criação e gestão do cluster Kubernetes.

Armazenamento persistente para os serviços na nuvem de contêineres

Atualmente, são utilizados 4 tipos de armazenamento persistente: cephfs, rbd, ISCSI e NFS. Abaixo podemos ver exemplos de utilização de cada um nos nossos serviços.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: fogproject-mysql
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteOnce
  storageClassName: fogproject-mysql
  cephfs:
    monitors:
    - 10.10.10.1:6789
    - 10.10.10.5:6789
    - 10.10.10.6:6789
    path: /kubernetes/ifsc/sje/srv/fog/data/mysql
    user: admin
    secretRef:
      name: ceph-secret

  rbd:
    monitors:
    - 10.10.10.1:6789
    - 10.10.10.5:6789
    - 10.10.10.6:6789
    pool: kube
    image: quartus
    fsType: ext4
    readOnly: false
    user: admin
    secretRef:
      name: ceph-secret-rbd

  iscsi:
    targetPortal: 172.18.31.1:3260
    iscsiInterface: default
    iqn: iqn.1992-04.com.emc:cx.ckm00123700157.a4
    lun: 0
    initiatorName: iqn.2019-06.pv-bareos-sd-continente:00:2955d7e72762
    fsType: ext4
    readOnly: false
    chapAuthDiscovery: true
    chapAuthSession: true
    secretRef:
      name: chap-secret-pv-bareos-sd
  storageClassName: pv-bareos-sd-continente-bkp

  mountOptions:
    - nolock
    - nfsvers=3
  nfs:
    server: 191.36.8.71
    path: /nfs_kubernetes/kubernetes/ifsc/sje/a/home