maratsh

Введение

Software Configuration Management - очень интересная и полезная тема, к которой должен придти каждый вменяемый системный администратор. ПО SCM позволяет получать одинаковый воспроизводимый результат на большим количестве машин с разным окружением за короткое время. Кроме того, использование SCM позволяет более четко понимать архитектуру разворачиваемой системы, а описание при помощи “рецептов” или “состояний” больше похоже на проектирование, нежели на настройку. Управлением конфигурациями пришло из производства, где конфиугурацией было сочетание состава деталей и их взаимного расположение.

Сегодня выбор ПО для SCM довольно широкий, в статье же речь пойдет о такой обойденной вниманием харба новике , да и вообще малоизвестной в рунете системе как Salt.

Описание

Установка

В Ubuntu подключаем ppa:saltstack/salt, выполняем:

apt-get install salt-master
apt-get install salt-minion

Начальная настройка

interface: 0.0.0.0 # мастер процесс принимает входящие подключения на этом ip
publish_port: 4505 #порт для входящих подключений
user: root #пользователь, от которого работает salt
worker_threads: 5 #количество потоков мастера
file_roots: #Описание папок файл сервера
base:
 - /srv/salt

Файл minion распологается на миньонах(клиентах) обязательно требует 2 параметра:

master: master.example.com #адрес master’а
id: minion.example.com

Директория /etc/salt/pki содержит ключи аутентификации.

Настроив мастера и миньона перезапускаем процессы:

root@master.example.com:/# /etc/init.d/salt-master restart
root@minion.example.com:/# /etc/init.d/salt-minion restart

Теперь необоходимо авторизовать minion на master’e. Делать это нужно от того пользователя, под которым выполняется salt-master.

Просмотрим список всех ключей, про которые знает наш мастер:

root@master.example.com:/# salt-key -L
Unaccepted Keys:
minion.example.com
Accepted Keys:
Rejected:

Примем ключ с вновь созданного миньона:

root@master.example.com:/# salt-key -a minion.example.com

Теперь снова посмотрим список ключей:

root@master.example.com:/# salt-key -L
Unaccepted Keys:
Accepted Keys:
minion.example.com
Rejected:

Для переименования миньона процедуру необходимо повторить заново, сначала удалив старый ключ:

root@master.example.com:/# salt-key -d minion.example.com

Миньон активирован на мастере и может принмать от него команды:

root@master.example.com:/# salt 'minion.example.com' test.ping
minion.example.com: True

Здесь ‘minion.example.com’ - цель, на которой будет выполнена команда. Можно использовать регекспы, например ‘*web*example.com’, а также ключи Grains. test - один из модулей salt. ping - метод модуля test.

Просмотреть список всех встроенных модулей можно в документации или выполнив команду:

root@master.example.com:/# salt '*' sys.doc | less

Модули можно легко дописывать и на лету подключать к salt.

State

Файл top .sls описывает какие states к каким миньоном должен применять master.

#/srv/salt/top.sls
base:
  ‘target’
    - app

Файл app.sls описывает какое либо состояние, к которому миньон должен придти:

#/srv/salt/app.sls
app:
  pkg:
    - installed
  service:
    - running
    - enabled: True

Чтобы применить state на миньонах необходимо выполнить команду

root@master.example.com:/# salt '*' state.highstate

Результатом будет состояние системы после применения описанных state. В случае неудачи текст будет красным, в случае успешного применения синим. Отображаются только изменения состояния.

Чтобы только протестировать, но не применять изменения, используется аргумент test

root@master.example.com:/# salt ‘*’ state.highstate test

app.sls также может быть папкой, тогда файл с состоянием будет называться init.sls - /srv/salt/app/init.sls

app:
  pkg:
    - installed
    - require:
      - cmd.run: app-repo
  service:
    - running
    - enabled: True
    - watch:
       - file.managed: /etc/app/app.conf

/etc/app/app.conf:
  file.managed:
    - source: salt://app/app.conf
    - require:
       - pkg: app

app-repo:
  cmd.run:
    - run
    - name: ‘echo |  apt-add-repository repo’
    - unless: ‘'apt-key list | grep 00000’

К последовательности выполнения не относится, но часто используется вместе с order такая опция как failhard

Grains

Изначально grains cодержит такую информацию как id, os, arch, fqdn, kernel и другие 45 динамических параметров системы. Эти базовые параметры миньон собирает самостоятельно при старте и они могут быть расширены. Salt просто выполняет все публичные функции в директории file_roots (/srv/salt/_grains) . Функция должна возвращать тип dict. Пример расширения grains можно увидеть здесь.

#/etc/salt/minon
grains:
  roles:
    - webserver
    - memcache
  deployment: datacenter4
  cabinet: 13
  cab_u: 14-15

Чтобы начать использовать grains выполним команду:

root@master.example.com:/# salt ‘*’ grains.items

root@master.example.com:/# salt -G ‘os:Ubuntu’ grains.item osrelease

Результатом команды будет версия Убунты со всех миньонов.

#/srv/salt/app/init.sls
app:
  pkg:
    - installed
    - require:
      - cmd.run: app-repo
   {% if grains['os'] == 'RedHat' %}
   - name: package_name
   {% if grains['os'] == 'Ubuntu' %}
   - name: name_package
   {% endif %}
  service:
    - running
    - enabled: True
    - watch:
       - file.managed: /etc/app/app.conf

/etc/app/app.conf:
  file.managed:
    - source: salt://app/app.conf
    - require:
       - pkg: app

app-repo:
  {% if grains['os'] == 'RedHat' %}
  cmd.run:
    - run
    - name ‘rpm -ivh repo_uri’
    - unless ‘yum repolist | grep repo’
    {% elif grains['os'] == 'Ubuntu' %}
   cmd.run:
    - run
    - name: ‘echo |  apt-add-repository repo’
    - unless: ‘'apt-key list | grep repo_key’
  {% endif %}

Применив этот state к своим миньонам под управлением Redhat и Ubuntu вы получите одинаковый результат.

...
/etc/app/app.conf
  file.managed:
    - source: salt://app/app.conf
    - template: jinja
    - require:
       - pkg: app
...

#/srv/salt/app/app.conf
...
Hostname={{ grains['fqdn'] }}
...

Ресурсы

Документация http://salt.readthedocs.org/en/latest/index.html

Основы MTU

Основной факт в области сетевых технологий, в том, что не все технологии работают на одном уровне. Одним из отличительных особенностей технологий канального layer2 уровня является максимальая полезная нагрузка передаваемого фрейма. (обычно называемый Maximum Transmission Unit - MTU). Например, обычные пакеты Ethernet могут быть до 1518 байт (в том числе CRC - байты), но они могут передать только 1500 байт полезной нагрузки если вы используйте инкапсуляцию по умолчанию.  При использовании SNAP инкапсляции размер полезной нагрузки (maximum payload блеать)  уменьшается до до 1492 байт. Token Ring и FDDI может  передавать намного большие пакеты и использовать большие размеры пакетов для уменьшения накладных расходов при выскоскоростной передаче данных в одноранговых (p2p) сетях.

Примечание.

Фреймы, большие чем 1518 байт (jumbo), применяемые в Fast Ethernet and Gigabit Ethernet environments позволили получить те же результаты.

С другой стороны, медленные последовательные линки используют меньший размер MTU чтобы уменьшить  serialization delay. Передача одного 1500-байтного пакета на 64kbps линке занимает почти 200ms. Такое поведение редко можно увидеть сегодня в связи с широким  распространением  фрагментации и чередования канала (LFI) по каналам PPP.

Инкапсуляции и туннелирования добавляют свои собственные ограничения: например, если вы используйте PPP over  Ethernet, заголовок PPPoE занимает восемь байтов из Ethernet полезной нагрузки, оставляя 1492 байт для IP пакета. Аналогично, Generic Routing Protocol (GRE) использует 24 байт заголовка, снижая MTU внутри GRE до 1476 байт. Очевидно, что сочетание различных методов инкапсуляции еще больше снижает размер MTU. MTU GRE- туннеля запущенного поверх ADSL является 1468 байт.

Технические подробности

Хотя заголовок GRE всего 4 байта (если вы не используете GRE ключ, который расширяет заголовок GRE до восьми байт), IPoverIP инкапсуляция требует дополнительный заголовок IP (20 байт), в результате 24 байта накладных расходов (overhead).  Чистый IPoverIP туннель настроенный в режиме  IPIP отнимает 20 байт.

IPSec еще больше усложняет расчеты MTU, так как размер заголовка IPSec, вставляемый в  пакет IP зависит от параметров IPSec transform sets (сочетания режима туннелирования, шифрования, использования NAT-T и паддинг 8 или 16 байтных блоков применяется.

Примечание

Оригинальная парадигма IOS, где зашифрованные пакеты проходят через тот, же интерфейс, что и зашифрованный трафик не поможет, так как MTU больше не свойство интерфейса. Размер MTU меняется в зависимости от того, зашифрован пакет или нет.

Оригинал: The never-encding story of ip fragmentation