Настройка репликации LDAP Multimaster

В какой-то момент понадобилось старую схему LDAP с одиноким сервисом переделать в что-то более надежное и устойчивое, способное выдерживать сбои и держать большую нагрузку. После недолгих изысканий было принято решение реализовать схему мастер-мастер. Удобство данной схемы в равноценности всех серверов в реплике и возможность вносить изменения на любом сервере. Устанавливать буду на сервера с Debian Linux тут это довольно просто делается. Конфиги будут хранится в самом LDAP и тоже будут реплицироваться между серверами. Сервера будут server1.prod.local и server2.prod.local. Итак, поехали.

Устанавливаем необходимые пакеты

apt-get install slapd ldap-utils

Далее начинаем прописывать конфиги, конфиги будут храниться в самом LDAP так что будем все конфигурить через ldiff с помощью команды

ldapmodify -Y EXTERNAL -H ldapi:/// -f 1.ldiff

На обоих серверах прописываем ID – ServerID (у каждого сервера свой) следующим ldiff

dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1

Добавляем пароль для сервиса репликации конфигов на обоих серверах

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: jcb8332jf30

Включаем модуль для репликации syncprov на обоих серверах

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: {1}syncprov.la

На обоих серверах прописываем сервера с которыми у нас будет проходить репликация

dn: cn=config
changetype: modify
add: olcServerID
olcServerID: 1 ldap://server1.prod.local
olcServerID: 2 ldap://server2.prod.local

Добавляем оверлей на обоих серверах чтобы пошла репликация

dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov

Включаем репликацию конфигов, это тоже делаем на обоих серверах

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcSyncRepl
olcSyncRepl: rid=001 provider=ldap://server1.prod.local binddn="cn=admin,cn=config"
bindmethod=simple credentials=ck3u8gj3
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=002 provider=ldap://server2.prod.local binddn="cn=admin,cn=config"
bindmethod=simple credentials=ck3u8gj3
searchbase="cn=config" type=refreshAndPersist
retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE

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

ldapmodify -vvvvv -D "cn=admin,dc=prod" -W -H ldapi:/// -f sync.diff

dn: cn=sync,dc=prof
changetype: add
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: sync
description: Syncrepl user for mirrormode operation
userPassword: {SSHA}n+8YKycr9Q/GpuCf4sDfSOQ+zg3csv3Ae

Прописываем тем же способом acl

dn: olcDatabase={1}hdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn="cn=proxy,dc=prod" read by dn="cn=manager,dc=prod" write by dn="cn=sync,dc=prod" read by * none
olcAccess: {1}to dn.base="" by * read
olcAccess: {2}to * by self write by dn="cn=admin,dc=prod" write by * read

Включаем репликацию

dn: olcDatabase={1}hdb,cn=config
changeType: modify
add: olcSyncrepl
olcSyncrepl: rid=003 provider=ldap://server1.prod.local bindmethod=simple binddn="cn=sync,dc=fs" credentials=vkj48gfj searchbase="dc=prod" schemachecking=on type=refreshAndPersist retry="5 5 300 5" timeout=1
olcSyncRepl: rid=004 provider=ldap://server1.prod.local binddn="cn=sync,dc=prod" bindmethod=simple credentials=vkj48gfj searchbase="dc=prod" schemachecking=on type=refreshAndPersist retry="5 5 300 5" timeout=1
-
add: olcMirrorMode
olcMirrorMode: TRUE

Добавляем индексы на нужные поля

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: objectClass eq
olcDbIndex: cn eq
olcDbIndex: gidNumber eq
olcDbIndex: memberUid eq
olcDbIndex: uid eq
olcDbIndex: uidNumber eq
olcDbIndex: uniqueMember eq
olcDbIndex: accessTo eq
olcDbIndex: entryUUID eq

После этого нужно выключить сервер slapd (/etc/init.d/slapd stop) и выполнить команду

slapindex

Которая создаст необходимые индексы для базы. И включить сервер. Это надо сделать на обоих серверах
Добавляем лимиты чтобы все работало без ошибок даже при большом количестве полей

dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcLimits
olcLimits: dn.exact="cn=sync,dc=prod" time.soft=unlimited time.hard=unlimited size.soft=unlimited size.hard=unlimited
-
add: olcSizeLimit
olcSizeLimit: 10000
-
replace: olcDbConfig
olcDbConfig: {0}set_cachesize 0 209715200 1
olcDbConfig: {1}set_lk_max_objects 1024000
olcDbConfig: {2}set_lk_max_locks 10240
olcDbConfig: {3}set_lk_max_lockers 10240

В целом конфигурация основных моментов закончена, репликация баз где конфиги и базы где хранятся данные уже работает.

Настраиваем бекап, бекап делается через простой скриптик

backup.sh
#!/bin/sh
YMD=`date +%Y.%m.%d-%HHours`;
slapcat > /etc/ldap/ldap.ldiff;
cd /root/ldap-backup/files;
tar c /etc/ldap/ >$YMD-server1-ldap-etc.tar; gzip $YMD-server1-ldap-etc.tar;

В случае необходимости восстановиться из бекапа делаем это так

restore.sh
#!/bin/sh
/etc/init.d/slapd stop;
rm /var/lib/ldap/*;
rm /root/ldap-backup/etc -rf;
slapadd -l /root/ldap-backup/etc/ldap/ldap.ldiff;
chown openldap:openldap /var/lib/ldap -R

/etc/init.d/slapd start;

 

Добавил статью про настройку TLS для соединения с LDAP

Настройка сервера точного времени на базе 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 или любое другое имеющее возможность получать данные о точном времени, и которое можно подключить к серверу и получать с него данные. Но это совсем другая задача.

Балансировка нагрузки

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

Начните получать прибыль сейчас!

Обращайтесь

 

Резервное копирование

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

 

 
     Что такое именно “правильное” резервирование данных? Тут, как и в любом другом деле, есть много нюансов и вопросов которые необходимо учитывать. Где хранить данные, в каком формате, так чтобы можно было быстро все восстановить, в какое время и какие типы данных лучше сохранить, так чтобы это не сказалось на производительности сайта. Да и много еще другого. В любом случае бекап, это такая штука, которую хочется один раз сделать и забыть. Но лучше так не поступать, а периодически проверять все ли там хорошо.
 
     Бекап с виду простая штука, но:
  •      Если вы хотите быть уверенны, что все ваши данные сохраняются вовремя и гарантированно восстанавливаются.
  •      Вам надо, чтобы окно бекапа, для всех видов данных спланировано так чтобы не мешать работе сайта.
  •      Если вы хотите быть уверенны, что бекап БД и других источников данных не приведет к перерывам в работе
  •      Если вы хотите максимально быстро восстановить работу сайта из резервной копии после гибели основных данных и знать как это правильно делать
 
     То имеет смысл обратиться к нам, за организацией правильной схемы бекапа вашего проекта. Мы не только делаем бекапы, мы проверяем, что из них можно восстановиться.
 

Обращайтесь

Консалтинг

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

 
     Часто проблемы не видны изнутри, а иногда на них просто не обращают внимания считая незначительными. Взгляд со стороны может понять причину остановки в развитии, то что мешает вашему проекту расти и развиваться. Найти новый путь в решении проблем, которые долго были причиной вашей головной боли. Подсказать новые варианты развития и поиска выходов из технологического тупика.
 
     Наш совет будет вам необходим если:
 
  •      Вы не знаете какой набор технологий лучше всего использовать для вашего проекта дальше.
  •      Есть проблемы с производительностью, но непонятно в чем причина и где узкое место.
  •      Ваш проект превращается в неуправляемое нечто, а вы оказались под лавиной проблем, которые приходится решать постоянно.
  •      Вам нужен план по техническому развитию проекта, с учетом роста нагрузки и использования различных технологий.
  •      Нужен свежий взгляд на ваш проект для оценки всех возможных технологических проблем и путей дальнейшего развития.
     В любом случае, вариантов, когда требуется, свежий взгляд эксперта всегда много, просто опишите вашу задачу нам и мы постараемся вам помочь.
 

Обращайтесь