Infrastrukturní DevOps s HPE OneView

• Infrastrukturní DevOps s HPE OneView (1) – Infrastructure as Code
• Infrastrukturní DevOps s HPE OneView (2) – API
• Infrastrukturní DevOps s HPE OneView (3) – Message bus
• Infrastrukturní DevOps s HPE OneView (4) – PowerShell
• Infrastrukturní DevOps s HPE OneView (5) – PowerShell skripty
• Infrastrukturní DevOps s HPE OneView (6) – Python
• Infrastrukturní DevOps s HPE OneView (7) – Python skripty
• Infrastrukturní DevOps s HPE OneView (8) – vaše vlastní aplikace s Grommet
• Infrastrukturní DevOps s HPE OneView (9) – Ansible a infrastruktura
• Infrastrukturní DevOps s HPE OneView (10) – Ansible a Blade networking
• Infrastrukturní DevOps s HPE OneView (11) – Ansible a síťový fabric
• Infrastrukturní DevOps s HPE OneView (12) – Ansible a servery

Pokračujme ve zkoumání příkladového Ansible playbooku pro automatizace vaší infrastruktury způsobem Infrastructure as code a Desired State. V minulém díle jsme si připravili networking z hlediska konektivity – připojení serverových žiletek do LAN a SAN, definice VLAN, odchozích portů a tak podobně. Dnes si do automatizace přidáme i externí síťový svět, konkrétně top-of-rack prvek.

Síťařina a Ansible

Následující příklad využívá Ansible modulů pro HPE prvky pro datová centra s operačním systémem Comware. Stejným způsobem ale můžete využít module pro Arista networks, které má od listopadu HPE ve svém portfoliu. Pokud sázíte na open source, můžete nasadit Ansible nad OpenSwitch. Všechny tyto varianty má HPE ve svém portfoliu. Podobných výsledků ale dostanete i s řešeními jiných výrobců. Ansible moduly existují třeba pro Dell, Juniper JunOS, Cisco IOS i NXOS.

Praktický příklad

Připomeňme si část hlavního playbooku (main.yaml), která se týká dnešního tématu:

- name: Top-of-rack networking
  hosts: switches
  gather_facts: no
  connection: local
  vars:
    state: present
  vars_files:
    - config.yaml
  roles:
    - tor-networking

Podívejme se také na kousek z našeho config.yaml. V něm jsme definovali VLANy a externí konektivitu. V minulém díle jsme to využívali pro konfiguraci blade switche, dnes totéž provedeme na druhé straně, tedy na top-of-rack prvku (pro jednoduchost jsou všechny blade skříně napojeny na jeden logický ToR prvek, ale samozřejmě není problém příklad rozšířit na podstatně komplexnější prostředí).

vlans:
  - id: 101
    name: Prod-101
  - id: 102
    name: Prod-102
  - id: 103
    name: Dev-103

logical_interconnect_group: FlexFabric
connectivity_enclosures:
  - logical_interconnects:
    - module: Encl1, interconnect 1
      ports:
        - X2
        - X4
      switchports:
        - GigabitEthernet 1/0/2
        - GigabitEthernet 1/0/3
      switch_link_aggregation_group: 1
    - module: Encl1, interconnect 2
      ports:
        - X2
        - X4
      switchports:
        - GigabitEthernet 1/0/4
        - GigabitEthernet 1/0/5
      switch_link_aggregation_group: 2

Všimněte si, že máme popsanou vazbu mezi externími porty blade šasí a porty v ToR prvku s tím, že v některých případech definujeme ještě číslo agregační skupiny, tedy požadujeme vytvoření LACP linkové agregace.

Pojďme tedy nahlédnout do tasků v roli, která nastavuje síťové prostředí. Pokud byste místo Comware použili Arista, OpenSwitch nebo Cisco Nexus, bude to velmi podobné co do konceptu.

Nejlprve se ujistíme, že máme vytvořeny všechny potřebné VLANy. Koncept Desired state znamená, že pokud nějaká chybí (například jsme přidali novou do config.yaml), Ansible uvede náš prvek do požadovaného stavu (tedy chybějící VLAN vytvoří).

- name: Ensure that VLANs exist
  comware_vlan:
    state: "{{ state }}"
    vlanid: "{{ item.id }}"
    name: "{{ item.name }}"
    username: "{{ switch_username }}"
    password: "{{ switch_password }}"
    hostname: "{{ inventory_hostname }}"
  with_items: "{{ vlans }}"

V případě Comware potřebujeme vytvořit permitted vlan string. To je to, co je nastaveno na portech ve smyslu výčet VLAN, která portem mohou procházet. Je to textový zápis (např. 1,10,20,300), tak si ho tímto způsobem připravíme (pozn.: jiné moduly pro jiné typy zařízení mohou používat jiný přístup, například výčet VLAN ve formě pole – na principu se ale mnoho nemění).

- name: Create permited VLANs string
  set_fact:
    permitted_vlans: "{{ vlans | map(attribute='id') | join(',') }}"

Teď už pojďme port a za portem a nastavujme. Pro zjednodušení tohle děláme zavoláním jiného vnořeného playbooku vždy pro každý propojovací prvek blade šasí.

- name: Ensure ports are configured
  include: ports.yaml
  with_items: "{{ connectivity_enclosures }}"

Co tedy playbook ports.yaml dělá?

Nejprve se ujistíme, že máme vytvořenou linovou agregaci, tedy virtuální porty (BAGG či chcete-li port-channel). Nicméně to provedeme pouze v případě, že je to v config.yaml požadováno.

- name: Ensure link aggregation is configured
  comware_portchannel:
    state: "{{ state }}"
    group: "{{ item.switch_link_aggregation_group }}"
    members: "{{ item.switchports }}"
    mode: dynamic
    type: bridged
    username: "{{ switch_username }}"
    password: "{{ switch_password }}"
    hostname: "{{ inventory_hostname }}"
  with_items: "{{ item.logical_interconnects }}"
  when: item.switch_link_aggregation_group is defined

Pak nastavíme povolené VLAN na potřebných portech. Uděláme to zvlášť pro porty, které nejsou v linkové agregaci – tam použijeme cyklus a port nastavíme jeden po druhém. V případě linkové agregace už máme porty seskupené pod virtuální channel port, takže ten můžeme nastavit přímo bez cyklu.

- name: Ensure that VLANs are configured on standalone ports
  comware_switchport:
    state: "{{ state }}"
    name: "{{ item[1] }}"
    link_type: trunk
    permitted_vlans: "{{ permitted_vlans }}"
    username: "{{ switch_username }}"
    password: "{{ switch_password }}"
    hostname: "{{ inventory_hostname }}"
  with_subelements:
    - "{{ item.logical_interconnects }}"
    - switchports
  when: item[0].switch_link_aggregation_group is not defined

- name: Ensure that VLANs are configured on link aggregattion interfaces
  comware_switchport:
    state: "{{ state }}"
    name: "Bridge-Aggregation {{ item.switch_link_aggregation_group }}"
    link_type: trunk
    permitted_vlans: "{{ permitted_vlans }}"
    username: "{{ switch_username }}"
    password: "{{ switch_password }}"
    hostname: "{{ inventory_hostname }}"
  with_items: "{{ item.logical_interconnects }}"
  when: item.switch_link_aggregation_group is defined

Na závěr se vrátíme do hlavního tasku role uložíme konfiguraci prvku (aby si ji pamatoval i po restartu).

- name: Save switch configuration
  comware_save:
      username: "{{ switch_username }}"
      password: "{{ switch_password }}"
      hostname: "{{ inventory_hostname }}"

Náš příklad Infrastructure as Code s použítím HPE OneView pro servery, storage a kontektivitu směrem do LAN a SAN a HPE Comware pro síťové propojení jednotlivých šasí jsme rozvinuli z hlediska síťařiny a příště si už vytvoříme serverový profil a slavnostně naše servery vytvoříme a spustíme.