Настройка сервера точного времени на базе NTP

Для работы сложной инфраструктуры, когда много сервисов работают одновременно очень важно иметь в пределах общего IT пространства одинаковое время на всех серверах. Самое удобное это делать с помощью автоматической синхронизацией с серверами точного времени. В большинстве случаев можно пользоваться общедоступными серверами, которых довольно много в интернете. Но в случае организации замкнутой среды, да и вообще для тех кто предпочитается все контролировать, хорошим вариантом будет организация своего собственного сервера точного времени, а лучше двух, для надежности.

     Использовать для своей синхронизации они будут сервера из того же интернета, и для достижения большей точности (stratum 2 и выше) будем выбирать наиболее точные и надежные. Список серверов по регионам можно подсмотреть тут http://support.ntp.org/bin/view/Servers/StratumOneTimeServers . Как правило стабильных открытых серверов со stratum 1 (непосредственно подключенных к источнику точного времени) не так много и нагрузка на них довольно большая. Поэтому создания своего сервера для синхронизации это в том числе пусть снять лишнюю нагрузку с них и получить свой стабильный сервер для точного времени.
     Для настройки возьмем старый, добрый сервер NTP. Не важно на какой версии ОС вы будете ее ставить, конфиг одинаков везде. Выложу сразу итоговую конфигурацию и потом расскажу что к чему и зачем.
 interface listen 10.11.12.2
 interface listen 188.8.88.8
 interface drop 10.11.12.1
 interface drop 188.8.88.8
 interface ignore wildcard
 interface drop lo

 server 91.226.136.139
 server 195.91.239.8
 server 95.140.94.2
 server 77.234.201.218
 server 77.37.146.85

 driftfile /var/lib/ntp/ntp.drift
 logconfig =all
 logfile /var/log/ntpd.log

 restrict default ignore
 restrict 127.0.0.1

 restrict 91.226.136.139 noquery notrap
 restrict 195.91.239.8 noquery notrap
 restrict 95.140.94.2 noquery notrap
 restrict 77.234.201.218 noquery notrap
 restrict 77.37.146.85 noquery notrap

 restrict 10.11.12.0 mask 255.255.255.0 nomodify notrap
 restrict 10.14.0.0 mask 255.255.0.0 nomodify notrap
     Итак, что есть что
 interface listen 10.11.12.2
 interface listen 188.8.88.8
 interface drop 10.11.12.1
 interface drop 188.8.88.8
 interface ignore wildcard
 interface drop lo
     В этом блоке мы определяем на каких интерфейсах и адресах мы разрешим работать NTP, а где запрещаем если надо.
 server 91.226.136.139
 server 195.91.239.8
 server 95.140.94.2
 server 77.234.201.218
 server 77.37.146.85
     Здесь прописываем сервера к которым мы будем обращаться за синхронизацией, среди них есть несколько stratum 1 так, итоговый stratum нашего сервера будет на уровне 2.
 driftfile /var/lib/ntp/ntp.drift
 logconfig =all
 logfile /var/log/ntpd.log
     Внутренние настройки NTP по поводу того где будет лежать логи, drift-файл и уровень логирования
 restrict 91.226.136.139 noquery notrap
 restrict 195.91.239.8 noquery notrap
 restrict 95.140.94.2 noquery notrap
 restrict 77.234.201.218 noquery notrap
 restrict 77.37.146.85 noquery notrap

 restrict 10.11.12.0 mask 255.255.255.0 nomodify notrap
 restrict 10.14.0.0 mask 255.255.0.0 nomodify notrap
     Настройки того кому можно и как обращаться к данному серверу, кому попало лазать не следует, раз мы делаем приватный сервер только для своих. В случае желания сделать открытый сервер для всех настройки будут уже совсем другие. Но это история для другой статьи совсем.

Запускаем сервер и смотрим что он выдает по своим пирам, у меня после некоторого времени работы получилось примерно так

 #ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
 ==============================================================================
 +n44.time2.d6.hs .GPS.            1 u 1019 1024  377   44.560   -5.584   3.620
 *195.91.239.8    .PPS.            1 u  880 1024  377    8.200    1.835   0.801
 -95.140.94.2     194.190.168.1    2 u  700 1024  377    8.407    5.305   0.647
 -glavhost.com    194.190.168.1    2 u  939 1024  377    8.340    4.098  46.622
 +broadband-77-37 46.46.152.214    2 u  793 1024  377    9.088    0.569   0.432
Теперь можно настроить клиента, как ни удивительно но это опять таки будет NTP
Для клиентов конфиг выглядит вот таким образом:
server 10.11.12.2 prefer
server 10.11.13.2 prefer
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntpd.log
restrict default ignore
restrict 127.0.0.1
restrict 10.11.12.2 noquery notrap
restrict 10.11.13.2 noquery notrap
restrict 10.11.12.0 mask 255.255.248.0 nomodify notrap
     Урезанная версия конфига нашего верхнего сервера, где в качестве пиров для получения точного времени указаны сервер (ы) который мы настроили перед этим. Дав ему поработать немного, чтобы синхронизироваться и выполнив ntpq
# ntpq -p
      remote           refid      st t when poll reach   delay   offset  jitter
 ==============================================================================
 +10.11.12.2    195.91.239.8     2 u  947 1024  377    0.157    1.241   1.148
 *10.11.13.2  195.91.239.8     2 u  847 1024  377    0.158   -0.689   0.194
     Как то так. Как видно, наши корневые сервера определяются как stratum 2, что в общем-то неплохо и для большинства задач хватает, если вам требуется точность на уровне stratum 1, что в общем-то маловероятно, то нужно приобретать устройство GPRS, Glonass или любое другое имеющее возможность получать данные о точном времени, и которое можно подключить к серверу и получать с него данные. Но это совсем другая задача.

Заметки о Juniper: SRX 100 в качестве офисного роутера, часть 1

Некоторое время назад у меня а столе появилась замечательная коробочка, с надписью Juniper Network сверху и в веселой синенькой расцветке. Сразу возникла идея заменить старый роутер под FreeBSD, на эту маленькую машинку. В общем-то именно для этой цели он и предназначался. Торопиться было некуда, спокойно и неспешно я принялся за дело.
     Поскольку сеть была не новая, все довольно обширно и нетривиально, то предстояло решить несколько проблем, ну и параллельно немного научиться работе с Джуниперами. До  этого момента я с устройствами этой фирмы не встречался, а очень хотелось ими овладеть на хорошем уровне. Так что знакомство я начал с того, что подключился через этот роутер в интернет и постарался воссоздать в тестовой среде, нормальную рабочую среду нашей организации.
     Для начала подключаюсь через консольный порт, делается это просто и стандартным для всех свичей образом. У всех SRX есть преднастроенный конфиг, благодаря которому, он может начинать в качестве роутера из коробки. Конечно для этого должны быть соблюдены несколько условий, например то что внешний адрес аплинка он будет получаться через DHCP, что бывает очень редко, но это было легко исправить.  Итак, прописываем внешний адрес на порту:

   set interfaces fe-0/0/0 unit 0 family inet address 10.133.14.2/27

Допустим нам наш провайдер выдал именно такой. Эта машинка замечательно работает и с третьеуровневыми интерфейсами как мы видим, и делается это очень просто и удобно. Итак порт подключен к аплинку, шлюз пингуется, но интернета, как нет, так и не было. Чего-то видимо не хватает. Ага, нету маршрута, вообще никакого. Ок, добавляю маршрут для выхода во вне.

   set routing-options static route 0.0.0.0/0 next-hop 10.133.14.1

     Отлично, выход во вне есть, внешка заработала. Ну пол дела сделано (я конечно ошибся), начало положено. Теперь надо разобраться с внутренней сетью. По умолчанию, на порту fe-0/0/0 настроен внешний интерфейс (почему-то влан с id 3), а все остальные порты с 1 по 7 смотрят в локалку. Вот так как на картинке
srx100-default-configuration
     Мне такое не надо, но переделывать я буду все попозже. Сейчас втыкаюсь ноутбуком в порт 1 и получаю через DHCP адресок, это тоже работает. Пингуем что-нибудь во вне и получаем приятный взгляду отклик. Ну что же получается не все так страшно как казалось, можно работать с этой машинкой, без особых проблем. Дальше будет продолжение моих приключений с джунипером.

Juniper SRX100. Офисный роутер, часть 2

Убедившись в том, что основной функционал работает, захотелось чего-то большего, заюзать полный функционал этого устройства. Для начала делаю самые простые вещи по настройке и мониторингу. Завожу отдельного от рута пользователя с супер-привилегиями:

 

set system login user user1 full-name "User Userovich" class super-user authentication encrypted-password 'DerPassword'

 

     Теперь вылогиниваюсь и пытаюсь зайти под вновь созданным пользователем. Такс, чего-то не пускает, чтобы это могло быть?! Захожу вновь под системными пользователем и что же вижу? Так и есть, забыл закоммитить изменения. Да, команда commit, очень удобна и полезна, но к ней надо еще привыкнуть, поначалу постоянно забываешь про нее, но со временем начинаешь пользоваться на автомате. Так же удобно делать периодически, во время конфигурирования и перед самим коммитом, команду commit check, для проверки правильности введенных строк, и не вызывают ли они где-то конфликтов. Ну что же, добавляю изменения в конфиг командой commit и получаю нового пользователя из под которого и буду в дальнейшем работать.
     Что хотелось сделать еще? Хочу снимать статистику по snmp, например в кактус. Внешний адресок у меня есть уже, я его прописал, буду его опрашивать и снимать статистику. Что мне надо для этого сделать? Для начала, надо включить snmp на самом роутере, прописать правильное коммюнити и открыть для правильных адресов. Итак:

 

set snmp description "Office Router"
set snmp contact admins@example.com
set snmp community 1234567 authorization read-only
set snmp community 1234567 clients 10.100.100.99/32
set snmp community 1234567 clients 0.0.0.0/0 restrict

 

     Если по простому, я задал коммюнити 1234567 с правами только на чтение и только с одного адреса 10.100.100.99/32. Это не все, на SRX100 весь неразрешенный траффик на внешнем интерфейсе режется без вопросов, поэтому, надо snmp открыть для доступа извне:

 

set security zones security-zone untrust interfaces fe-0/0/0.0 host-inbound-traffic system-services snmp

 

     Далее, осталось завести все это дело в коллектор статистики, я пользуюсь кактусом, так что нахожу нужный шаблончик на форуме кактусоводов устанавливаю его в свой кактус, завожу роутер в систему и, через некоторое время, получаю красивые графики по всем нужным мне показателям и интерфейсам. Любопытный график по температуре получается, хорошо отражает то, что в SRX100 нет ни одного вентилятора. Не стоит его класть рядом с батареей, ох не стоит 🙂

Заметки о Nexenta: Подготовка к работе

Раз добрались до этого шага, значит большое дело, а именно сама установка системы с той или иной степенью успешности был вами победно завешен. Закончив победные пляски с бубнами, пора пиступать к следующему этапу — настройке и подготовке к работе. Что я под этим подразумеваю? Тут имеется несколько моментов.

Ну во первых я установил бы последние обновления. Это всегда важно и делать надо всегда и на любой системе, не важно для чего она предназначена. Обновления помогают спасти от многих проблем знаете. На Nexenta, обновления ставятся практически также как на Debian, однако со своими особенностями характерными для фич zfs. Здесь, при большом обновлении, снимается снепшот системного диска, таким образом, чтобы при каких-либо проблемах откатится на предыдущее состояние системы. Очень и очень удобно знаете ли. Поначалу непривычно, но очень впечатляет, когда к этому привыкаешь и осваиваешь в нужном объеме. Делается это с помощью команды apt-clone, примерно таким образом:

#apt-clone upgrade

This operation will upgrade your system using ZFS capabilities. Proceed ? (y/n) y

Updating APT sources ...
Initiating Nexenta upgrade procedure. Please wait...

Не забываем, что надо в /etc/apt/source.lst прописать правильные репозитории, откуда будут качаться обновления, все как в Debian/ Далее будет производится скачивание, и установка нужных пакетов в зависимости от того какая версия nexenta у вас установлена и какие пакеты нужно обновлять. apt-clone работает по тому же принципу что и apt-get за исключением создания снепшота после обновления и ребута после этого самого обновления, если он требуется конечно. Вообще процедура довольно безопасная, но я ее все равно немного побаиваюсь, поскольку первый раз когда я это делал, я запорол систему и у меня не грузилось больше ни чего и ни с какого снепшота. Видимо я что-то делал не так, но поскольку ход моих действить восстановить не представлялось никакой возможности, то это осталось тайной покрытой густым мраком.

После установки обновлений, стоит проверить что все работает по прежнему хорошо. Проверили? Очень хорошо, я и не сомневался, что все по прежнему работает. Далее, я обычно ставлю такую полезную приблуду как napp-it. Это бесплатный веб-интерфейс для управления всеми основными фишками системы, приложениями и вообще практически всем, что есть в системе. Очень удобная штука, особенно по началу, когда только постигаешь возможности системы и опыта не хватает все делать через консоль.

napp-it

 Ну а если у вас NexentaStor, то там необходимости ставить веб-интерфейс нету, там он уже есть, встроен уже разработчиками, остается только через него проапгрейдить систему и поставить нужные плагины, которые вам потребуются по работе. Через napp-it можно делать очень широкий спектр действий с системой, пулами, папками, ну и вообще всем всем. Единственно что он имеет тот же недостато что и все веб-интерфейсы, если операция занимает слишком много времени, она отвалиться по таймауту и резльтатов ее выполнения вы никогда не увидите. Но для таких задач есть консоль, она поможет со всем разобраться.

Важный момент, который я обычно делаю до ввода сервера в основную работу — это настройка аггрегации на сетевых карточках. Сетевых карточек в материнских платах сейчас ставят не мало, зачем использовать только одну если можно использовать все как одну. Для этого, правда, необходимо чтобы ваш свич, куда будут воткнуты эти сетевушки умел поддерживать стандрат IEEE 802.1AX. Вещь это распространенная, во всех более или менее нормальных свичах она есть. Как настраивать свич я рассказывать не буду, там все зависит от производителя. Что касается Nexenta, то там это делается командой dladm. Допустим у вас есть 2 интерфейса на материнке, которые видны как e1000g0 и e1000g1 и вы хотите их аггрегировать по активному типу, тогда комманда которую надо вам будет ввести в консоле, будет выглядеть следующим образом:

dladm create-aggr -L active -l e1000g0 -l e1000g1 aggr1

После выполнения этой команды создасться аггрегирующий интерфейс aggr1, который будет состоять из двух физических интерфейсов e1000g0 и e1000g1. Осталось прописать адреса в стартовые конфиги системы. Для это в каталоге /etc/ создаем файлик hostname.aggr1, куда добавляем всего одну строчку:

xxx.xxx.xxx.xxx netmask 255.255.255.0 broadcast + up

Где xxx.xxx.xxx.xxx это IP адрес. Маску тоже указываем правильную. Шлюз прописывается в файлике /etc/defaultrouter. Вот в общем-то и все, если со свичем у вас тоже все получится, то никаких проблем с использованием подобного рода аггрегации на этой системе не будет, а польза будет. Согласитесь, что совсем не хочется упереться в производительность сети на уже во всю работающем сервере и судорожно искать как эту проблему решить.

Заметки о Nexenta: Установка Nexenta

Доброго времени суток. Итак, вы уже определились с тем что действительно хотите поставить себе дистрибутив Nexenta для тех или иных целей, а так же вполне определились с тем железом куда собираетесь эту систему устанавливать. Соответсвенно логично перейти к следующему шагу — это установке самой системы. Сейчас на выбор есть 3 варианта, ну на самом деле 4-е, но StormOS я сюда не включаю, так как это чисто десктопный проект на базе nexenta. Так что сейчас имеются варианты с Nexenta Core, NexentaStor Community Edition и NexentaStor Enterprise Edition. В чем различия и что выбрать?

Различия прежде всего в функционале и дополнительном функционале, который предоставляется в Enterprise редакции, а так же в поддержке, которую можно получить. Если Nexenta Core, в своем базовом варианте, это просто голая система без красивого веб-интерефейса, но при этом с полным набором функций, который предоставляет zfs и система в целом, единственно,nexenta_install4 надо будет все настраивать самому через коммандную строку, ну или поставить napp-it, который выглядит и действует не хуже веб-интерфейса в NexentaStor. При этом в Core нет никаких ограничений на объем хранимого места или организацию кластера. А вот в NexentaStor Community Edition такие ограничения есть. Там есть ограничения на 18Тб хранимых данных на системе, число конечно не маленькое, но при существующих размерах дисков и данных хранимых на них, это квоту можно выбрать довольно легко. Так же присутствуют определенные ограничения на организацию кластерных систем ну и нет доп. функционала который присутствует в Enterprise Edition. А так в целом, все что надо тут есть, плюс сразу дают красивый веб-интерфейс. Шелл тоже есть, но он до определенный степени обрезан и унифицирован, все что надо можно сделать через него, но ничего больше, непривычно я бы сказал, но работать можно. Если же вы хотите работать без ограничений, плюс к этому получить дополнительные плюшки, тогда вам за Enterprise Edition. В ней, за ваши деньги вы получите полный функционал без лимитов и ограничений, плюс дополнительные плагины типа VM Datacenter, который позволяет интергировать сторадж в систему виртуализвации, например Xen или Hyper-V если вы содираетесь использовать ваше хранилице для этих целей, в целом удобно и позволяет многие вещи упростить, если это действительно необходимо.

Это был небольшой обзор по различным дистрибутивам и тем возможностям, которые они представляют. Думаю пришло время переходить к самой установке. А точнее к ее подготовительной части. Ведь перед тем как устанавливать систему, нужно ее где-то взять. Core Edition можно скачать на сайте http://www.nexenta.org. Что качается NexentaStor то за ней путь дорога лежит сюда http://nexenta.com. На этом же сайте можно пробить себе и лицензионный ключ, он вам понадобиться для установки NexentaStor. Закатываем дистрибутив на диск, и можно переходить непосредственно к самой установке.

 

Установка проста и не требует каких-то особых знаний или какого-то шаманизма, ну разве что у вас не будет каких-то приключений с железом, по типу того что я описывал в предыдущей статье. Но это скорее исключение чем правило. Саму установку я бы разделил, на 3 этапа. На первом этапе у вас загружается система установки, проверяются диски и прочее железо, проверяется возможность установки. Далее следует лицензионное соглашение, выбор часового пояса ну и самое интересное на этом этапе, это выбор дисков для установки. В Nexente, в отличии от например линуксовых систем, есть четкое разделение между системными дисками, дисками которые целиком и полностью оттданы под систему и дисками на которых хранятся данные. Это различие четко становиться видно во время этого этапа установки. Предлагается выбрать диски, которые будут заюзаны конкретно под систему и не под какие другие цели больше. Можно выбрать 1 диск или например 2 под зеркало, или еще больше если не жалко, так же можно выбрать диски под hot-spare в системный раздел. Будте внимательны в дальнейшем эти диски для организации пула хранилища использовать не получиться, так что выбирайте хорошенько подумав сколько дисков использовать под систему. Если дисков мало и жалко тратить ценный ресурс, то используйте 1 диск, если резерв есть, то 2 диска в зеркале будет лучше, для дополнительной надежности.

nexenta_install1

     После выбора дисков под систему, разбивать их не надо, да выбирать системные разделы не придется, все уже выбрано до вас и установиться в соответствии с шаблоном. В этом и заключается весь 2-й этап как я бы его обозвал. Разбиваются диски, организуется zfs-пул под системный раздел и копирутся файлы с системой на диск. После этого наступает время третьего этапа, где можно задать пользователей для доступа, пароль для рута, IP адреса. Завершаем установку и перезагружаемся в новую систему. Поздравляю система установлена и готова к работе. Точнее еще не совсем готова, но осталось не так много, о том как подготовить Nexenta Core к работе я расскажу в следующей статье.