NetApp + Ansible


Меня уже несколько раз на различных мероприятиях спрашивали по поводу первоначального конфигурирования массивов NetApp при помощи Ansible, да и статьи по Ansible, судя по статистике посещаемости моего блога, крайне популярны. Поэтому не будем отставать от трендов перехода к infrastructure as a code и поговорим о том, как быстро и просто сконфигурировать с нуля систему на Ontap.

Главная сложность массивов NetApp (но в том же и их прелесть), что вам для конфигурирования доступно практически всё, что вашей душе угодно. Такого количества параметров нет, пожалуй, ни у одного другого вендора СХД. Но в этом же и сложность, особенно учитывая «многослойность» системы и большое количество абстракций.
Настраивать всё это через GUI удовольствия действительно мало, да и порой это крайне неудобно. Можно использовать консоль — она понятна и читабельна, все команды в целом интуитивно понятны, но они длинные, их много и вам всё равно необходимо иметь некий чек-лист того, что вам необходимо настроить на системе, для того чтобы это было во-первых единообразно с остальными вашими системами, а во-вторых чтобы в большом количестве настроек не упустить и не забыть что-либо.
Но если вам всё равно необходимо хотя бы однажды описать всю конфигурацию, то почему бы не сделать это сразу в эталонном конфигурационном файле и далее уже по необходимости туда вносить изменения, необходимые для конкретных систем? Если вы не один занимаетесь поддержкой этих систем, то можно дополнить эту схему при помощи Git репозитория, куда можно складывать конфиги под каждую систему и каждый из администраторов сможет вносить в них изменения, и при этом всем будет понятно когда и по какой причине в конфиг для конкретной системы вносились изменения (при условии, что всё это документируется при коммитах, конечно же).
Да и вспомнить через пару лет как была сконфигурирована система намного быстрее и нагляднее при помощи одного конфигурационного файла, нежели проводить инвентаризацию системы через GUI или консоль.

Но немного о самих модулях NetApp для Ansible. NetApp пожалуй активнее всего развивает их среди остальных стораджовых вендоров. И лишь Pure дышит им в затылок. Поддержка NetApp не ограничивается только системами под управлением ONTAP, также есть модули как для SolidFire, так и для E-series. Есть даже модули для поддержки 7-mode в старых версиях Ansible (были удалены в 2.11).

И так, расскажу, как на мой взгляд лучше построить этот процесс, а вы уже сможете применить его под себя, внеся необходимые правки. Но прежде чем переходить к написанию конфигурационного файла, надо всё-таки подготовить нашу рабочую станцию к работе. Как разворачивается сам Ansible я писал в одной из своих старых статей «Ansible знакомимся с системой на примерах». Дополнительно к этому нам понадобится модуль для работы с системами NetApp. Когда вы работаете с Ansible, крайне важным является использование самой свежей версии модулей. Очень часто проблемы с плейбуками возникают из-за того, что написаны они, например, для версии 2.8, а в версии 2.9 уже многое что изменилось и надо заглянуть в документацию на предмет изменений, которых обычно довольно много, в том числе и новые возможности в модулях. Поэтому ставить будем из Git.

yum install git -y
git clone https://github.com/ansible/ansible.git ~/ansible-devel
cd ~/ansible-devel
git pull
cd ~/ansible-devel/lib/ansible
sudo yes|cp -aRv module_utils/netapp* /usr/lib/python2.7/site-packages/ansible/module_utils
sudo yes|cp -aRv modules/storage/netapp/* /usr/lib/python2.7/site-packages/ansible/modules/storage/netapp/

Условно разделим на 2 этапа наше конфигурирование:

  • Настройка параметров массива, которые не привязываются к SVM, а едины для всей системы
  • Создание и настройка SVM

Начну с того, что первоначальную настройку я делаю всё-таки на самом массиве — это настройка менеджмента нод и создание кластера, после чего мы уже, собственно, сможем получить удалённый доступ к системе. И ещё одно действие, которое я предпочитаю всё-таки делать руками, привязка дисков в контроллерам и создание агрегатов. Во-первых потому что в модуле NetApp для Ansible нет поддержки работы с дисками, а создание аггрегатов вручную делается мной уже просто на автоматизме при конфигурировании дисков. Хотя никто не запрещает вам использовать для этого и Ansible, ведь это действительно просто. Начинать нужно с того, что мы скажем нашему плейбуку — где именно он будет запускаться и определим некоторые переменные.

---
- hosts: localhost
  gather_facts: False
  name: System setup
  vars:
    hostname: 192.168.1.130
    username: admin
    password: pass

Если вы уже имели дело с Ansible, то скорее всего заметите, что мы указываем нашему плейбуку, что запускаться он будет на localhost, хотя обычно мы указываем там имена хостов или имена групп хостов. Дело в том, что для работа Ansible с ONTAP (да на самом деле и с ElementOS) идёт не через привычный ssh, а посредствам http/https при помощи модулей, которые мы устанавливали ранее.
А теперь буквально в несколько строк мы создадим 2 агрегата

  - name: Create Aggregates
    na_ontap_aggregate:
      state: present
      service_state: online
      name: "{{ item.aggr }}"
      disk_count: "{{ item.disk_count }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    loop:
      - { aggr: 'aggr1', disk_count: '13' }
      - { aggr: 'aggr2', disk_count: '13' }

Есть ещё одна задача, которую необходимо выполнить на новой системе — создание VLAN’ов на портах. Если мы используем классическую двухконтроллерную систему, то мы должны как минимум на 4 портах массива настроить пару VLAN’ов. Конечно это не всегда так, их может как больше, так и меньше, или, если вы используете ONTAP Select, у вас может быть вообще один контроллер и один порт. Но я покажу общую концепцию, которую можно будет применить потом к любому количеству портов.

  - name: Create VLANs
    na_ontap_net_vlan:
      state: present
      vlanid: "{{ item.vlanid }}"
      node: "{{ item.node }}"
      parent_interface: "{{ item.parent_interface }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    loop:
      - { node: 'korphome-01', vlanid: '13', parent_interface: 'e0a' }
      - { node: 'korphome-01', vlanid: '14', parent_interface: 'e0a' }
      - { node: 'korphome-01', vlanid: '15', parent_interface: 'e0a' }
      - { node: 'korphome-01', vlanid: '16', parent_interface: 'e0a' }

Всё в принципе просто. На каждой из нод нашей системы на портах e0a мы создаём интерфейс с 13 VLAN ID, а на e0b с 14. В данном случае я использую loop и метод создания виртуального интерфейса выполнится 4 раза с заданными параметрами. Это не самая сложная схема, чуть более сложный вариант использования циклов я применю при создании вольюмов на агрегатах чуть позже.
Следующий этап — создание IPspaces и Broadcast Domains.

  - name: Сreate broadcast domain
    na_ontap_broadcast_domain:
      state: present
      name: ansible_domain
      mtu: 1000
      ipspace: Default
      ports: ["korphome-01:e0a-13", "korphome-01:e0a-14"]
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

  - name: Create ipspace
    na_ontap_ipspace:
      state: present
      name: ansibleIpspace
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

И последним остаётся задать NTP сервер

  - name: Create NTP server
    na_ontap_ntp:
      state: present
      version: auto
      server_name: "3.ru.pool.ntp.org"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

Теперь определив в первом конфигурационном файле все необходимые нам параметры (а вы, подправив их под свои нужды), можем запустить данный плейбук и получить первоначальные настройки на нашей системе.

Не удивляйтесь что у меня настройки немного расходятся с тем, что я предлагаю делать, просто эксперименты я провожу на ONTAP Select у которого всего один “контроллер” и всего один диск. Чтобы не собирать весь конфиг по тексту статьи, для удобства я выложу полный листинг обоих плейбуков в конце статьи. При помощи na_ontap_user вы возможно захотите добавить ещё и пользователей в систему с различными правами доступа.

С первым плейбуком и предварительной настройкой системы мы закончили, переходим ко второму этапу — создание и конфигурирование SVM. Это как раз одна из тех виртуальных сущностей, которая есть в системах ONTAP. Почему я решил их разделить на 2 части? Потому, что по моему опыту — создавать и модифицировать SVM приходится намного чаще, чем остальные настройки. Раз мы создаём отдельный плейбук, то ещё раз определим как он будет запускаться и с какими переменными, добавив туда сразу и имя нашего SVM.

---
- hosts: localhost
  gather_facts: False
  name: Create SVM
  vars:
    hostname: 192.168.1.130
    username: admin
    password: pass
    vserver: AnsibleSVM

И первым делом, мы создаём саму сущностью SVM, которую будем уже дальше наполнять различными настройками.

  - name: SVM Create
    na_ontap_svm:
      state: present
      name: "{{ vserver }}"
      root_volume: "{{ vserver }}_root"
      root_volume_aggregate: aggr1
      root_volume_security_style: unix
      allowed_protocols: nfs,cifs,iscsi
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

Используется модуль na_ontap_svm, состояние указано в качестве present, т.е. мы его создаём. На самом деле, чтобы удалить какой-то элемент достаточно сменить present на absent, так что стоит быть внимательнее. Но по логике работы самого Ontap вы не сможете просто удалить SVM, предварительно нужно будет удалить всё его содержимое с данными (луны, вольюмы, шары) и некоторые связанные с ним настройки (igrop’ы, например), а уже потом удалять сам SVM. Но вернёмся к заданию создания SVM. Если вы работали с системами ONTAP, то большинство указанных параметров вам понятны. Имя SVM Create мы объявили в переменной в самом начале — AnsibleSVM, т.к. все наши настройки будут связаны именно с SVM, чтобы нам было достаточно только один раз его указать в конфигурационном файле для большей гибкости в далнейшем использовании этого конфига с другими системами. А вот последние 5 строк задачи создания SVM будут преследовать нас до самого конца. Как я уже говорил ранее, работа Ansible с ONTAP осуществляется посредством http/https и каждая задача — это отдельное обращение к массиву, для чего нам требуется каждый раз авторизовываться, говорить какой протокол мы используемся и что делать с сертификатом. Конечно это не совсем удобно и очень сильно раздувает конфигурационный файл.

Зададим настройки DNS

  - name: Create DNS
    na_ontap_dns:
      state: present
      vserver: "{{ vserver }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      domains: korphome.local
      nameservers: 192.168.1.216
      skip_validation: true
      https: true
      validate_certs: false

С применением loop, который мы использовали при создании VLAN’ов, мы создадим необходимые виртуальные интерфейсы.

  - name: Create interface
    na_ontap_interface:
      state: absent
      interface_name: "{{ item.interface_name }}"
      home_port: "{{ item.home_port }}"
      home_node: "{{ item.node }}"
      role: data
      protocols: "{{ item.protocols }}"
      admin_status: up
      firewall_policy: mgmt
      address: "{{ item.address }}"
      netmask: 255.255.255.0
      vserver: "{{ vserver }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    loop:
      - { node: 'korphome-01',  interface_name: '{{ vserver }}_iscsi_1', protocols: 'iscsi', home_port: 'e0a', address: '192.168.1.165' }
      - { node: 'korphome-01',  interface_name: '{{ vserver }}_iscsi_2', protocols: 'iscsi', home_port: 'e0a', address: '192.168.1.166' }
      - { node: 'korphome-01',  interface_name: '{{ vserver }}_data_1', protocols: 'nfs,cifs', home_port: 'e0a', address: '192.168.1.167' }
      - { node: 'korphome-01',  interface_name: '{{ vserver }}_data_2', protocols: 'nfs,cifs', home_port: 'e0a', address: '192.168.1.168' }

Как я уже упоминал выше — моя конфигурация будет казаться немного странной. В данном случае у меня весь трафик идёт через один единственный порт, но т.к. мы готовим всё-таки универсальный скрипт для физической системы, я хочу показать как он должен выглядеть в идеальном случае.
Одним из протоколов, с которым мы будем работать, который мы указали при создании SVM, будет iSCSI, мы также создали для него 2 интерфейса, через которые будет ходить трафик и теперь нам необходимо создать на SVM сам сервис iSCSI и запустить его.

  - name: Start iscsi service
    na_ontap_iscsi:
      state: absent
      service_state: started
      vserver: "{{ vserver }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

Следующим этапом станет создание группы инициаторов, которые будут работать с нашим массивом по iSCSI.

  - name: Create igroup
    na_ontap_igroup:
      state: absent
      name: ansibleIgroup
      initiator_group_type: iscsi
      ostype: vmware
      initiator: iqn.1998-01.com.vmware:esxi6-68316bc6,iqn.1991-05.com.microsoft:veeamv10
      vserver: "{{ vserver }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

Определяем произвольное имя группы хостов, задаём ostype и через запятую указываем iqn наших серверов. При создании SVM мы указали, что он будет работать ещё и с файловыми протоколами nfs,cifs и для них также необходимо сконфигурировать и запустить сервисы.

  - name: Start nfs service
    na_ontap_nfs:
      state: absent
      service_state: started
      vserver: "{{ vserver }}"
      nfsv3: disabled
      nfsv4: disabled
      nfsv41: enabled
      tcp: disabled
      udp: disabled
      vstorage_state: disabled
      nfsv4_id_domain: korphome.local
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
      
  - name: Create ans start cifs service
    na_ontap_cifs_server:
      state: absent
      cifs_server_name: ontap
      workgroup: korphome
      service_state: started
      vserver: "{{ vserver }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

Для NFS нам необходимо указать по какой из версий протокола у нас клиенты будут получать доступ, в описании к na_ontap_nfs есть параметры, связанные с правами доступа, которые вам тоже могут понадобится. А для CIFS достаточно указать только workgroup.

Теперь нам осталось организовать луны и шары, на которых собственно и будут храниться наши данные. Но прежде чем переходить к их созданию, немного поговорим об именовании. Дело в том, что в зависимости от проекта, я именую луны и вольюмы по-разному. Где-то это просто порядковые номер vol1, vol2, vol3. А для некоторых проектов мне необходимо указывать какие-то более человеческие имена, типа sevr1_db_2. От этого варианты генериции конфига для Ansible будут немного отличаться. Я покажу оба варианта, а вы уже сможете взять тот вариант, который больше подходит для вас. И так, первый вариант — числовое именование.

  - name: Volume Create
    na_ontap_volume:
      state: present
      name: "vol_{{ item.1.name }}"
      vserver: "{{ vserver }}"
      aggregate_name: "{{ item.0.aggr }}"
      size: 30
      size_unit: gb
      policy: default
      percent_snapshot_space: 0
      efficiency_policy: default      
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    loop: "{{ lookup('subelements', aggrs, 'volumes', {'skip_missing': True}) }}"
    vars:
      aggrs:
      - { name: "aggr1", volumes: [11,13,15,17] }
      - { name: "aggr2", volumes: [12,14,16,18] }

Здесь мы используем итератор внутри loop. Данный конфиг создаст 4 вольюма vol11, vol13, vol15, vol17 на агрегате aggr1 и 4 вольюма с чётными числами на втором агрегате. Не забываем внести изменения в size и size_unit и поправить percent_snapshot_space и efficiency_policy под свои требования.
Создать луны под этот шаблон именования будет также просто

  - name: Create LUN
    na_ontap_lun:
      state: present
      name: "lun_{{ item }}"
      flexvol_name: "vol_{{ item }}"
      vserver: "{{ vserver }}"
      size: 5
      size_unit: gb
      ostype: vmware
      space_reserve: no
      space_allocation: yes
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    with_sequence: start=11 end=18

with_sequence это такой же итератор, который создаст нам по одному луну на каждом из наших вольюмов. Не забываем внести изменения в size и size_unit и поправить percent_snapshot_space и efficiency_policy под свои требования. Изменяем ostype, если наши хосты не являются VMware и правим space_reserve и space_allocation, если хотите использовать другие параметры. Таким образом мы получим следующую структуру
aggr1/vol11/lun11
aggr2/vol12/lun12
aggr1/vol13/lun13
aggr2/vol14/lun14
aggr1/vol15/lun15
aggr2/vol16/lun16
aggr1/vol17/lun17
aggr2/vol18/lun18

Быстро и удобно, но не все отвечает требования задачи. Если мы хотим указывать какие-то конкретные имена вольюмов/лунов, то можно воспользоваться другим вариантом

  - name: Volume Create
    na_ontap_volume:
      state: present
      name: "vol_{{ item.1.name }}"
      vserver: "{{ vserver }}"
      aggregate_name: "{{ item.0.aggr }}"
      size: 30
      size_unit: gb
      policy: default
      percent_snapshot_space: 0
      efficiency_policy: default      
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    with_subelements:
      - "{{ volumes }}"
      - volume
    vars:
      volumes:
        - aggr: aggr1
          volume:
            - name: server1_db1_vol
            - name: server2_db1_vol
        - aggr: aggr2
          volume:
            - name: server1_db2_vol
            - name: server2_db2_vol

Также не забываем про size, size_unit, percent_snapshot_space и efficiency_policy. И по аналогии создадим луны

  - name: Create LUN
    na_ontap_lun:
      state: present
      name: "lun_{{ item }}"
      flexvol_name: "vol_{{ item }}"
      vserver: "{{ vserver }}"
      size: 5
      size_unit: mb
      ostype: vmware
      space_reserve: no
      space_allocation: yes
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    with_subelements:
      - "{{ volumes }}"
      - lun
    vars:
      volumes:
        - vol: server1_db1_vol
          lun:
            - name: server1_db1_lun
        - vol: server2_db1_vol
          lun:
            - name: server2_db1_lun
        - vol: server1_db2_vol
          lun:
            - name: server1_db2_lun
        - vol: server2_db2_vol
          lun:
            - name: server2_db2_lun

Здесь тоже не забудьте про параметры: size и size_unit, percent_snapshot_space, efficiency_policy, ostype, space_reserve и space_allocation. Честно скажу, этот вариант мне не сильно нравится, но иногда приходится использовать и его. Проблема в том, что это сильно увеличивает конфиг и снижает его читабельность. При этом потом такую же конструкцию придётся использовать при мапинге, т.к. нам нужно будет указывать целиком путь /vol/vol_name/lun_name. Потому что с итератором это делать всё-таки намного проще

  - name: Create LUN mapping
    na_ontap_lun_map:
      state: present
      initiator_group_name: ansibleIgroup
      lun_id: "{{ item }}"
      path: "/vol/vol_{{ item }}/lun_{{ item }}"
      vserver: "{{ vserver }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false
    with_sequence: start=11 end=18

Параметр lun_id в принципе можно не указывать, но удобнее, когда порядковый номер луна совпадает с Lun ID, который видно со стороны сервера. И главный параметр в этом конфиге — initiator_group_name, группа, которую мы создавали уже ранее и к которой мы мапим наши луны.
И последнее, что осталось нам сегодня сделать — создать CIFS и создать доступ по NFS.

  - name: Create CIFS share
    na_ontap_cifs:
      state: present
      share_name: Share
      path: /
      share_properties: browsable,oplocks
      symlink_properties: read_only,enable
      vserver: "{{ vserver }}"
      hostname: "{{ hostname }}"
      username: "{{ username }}"
      password: "{{ password }}"
      https: true
      validate_certs: false

Все share_properties описаны в документации к ONTAP vserver cifs share properties show, а параметры symlink_properties в Configuring UNIX symbolic link support on SMB shares.

Конечно в этой статья я описал далеко не все модули и даже не все возможности модулей, которые использовал для примеров. Но я и не ставил перед собой такой задачи, я лишь хотел показать, как можно удобно построить процесс настройки массивов под управлением ONTAP (в том числе и ONTAP Select). По сути, при помощи Ansible вы можете настроить практически всё тоже самое, что можете настроить из GUI (в CLI возможности конечно шире). Самое главное — сделать это будет удобнее и быстрее. Предварительно собираете необходимую для настройки информацию: ip-адреса для lif’ов, адреса dns, ntp, имена SVM и томов, быстро заполняете это в конфигурационном файле и за одну минуту производите настройку всей системы. Я считаю это отличным решением и потихоньку стараюсь внедрить этот подход у нас. Но а если у вас остались ещё вопросы, или что то не получается, можно написать мне или в канал Netapp.io в Slack.
Как и обещал, в конце полный листинги:
system_setup.yml
create_svm.yml

Один ответ на “NetApp + Ansible”

Добавить комментарий