Translate

вівторок, 25 грудня 2012 р.

Nginx as reverse proxy for Apache

Усім відомо, що Apache є стандартом де-факто для веб-серверів. Розробники деяких CMS взагалі рекомендують користуватись саме Apache, і для налаштування їх під інший веб-сервер іноді необхідно попотіти. Але також ні для кого не є секретом, що Apache - важкий і ресурсоємкий сервер і на великих проектах від себе показує, м'яко кажучи, не дуже.
Тож одним із самих швидких варіантів оптимізації буде використання веб-серверу Nginx, як фронтенду до Apache. Тобто Nginx буде обробляти всю статику (запити на картинки, джаваскрипти, css і тд), а у випадку якщо відбудеться запит на php-скрипт чи щось таке (динамічний контент) - запит буде відправлено на обробку нашому "жирному" другу Apache-у.
Як показує практика такий варіант значно (!) економить ресурси серверу, адже запущених дочірніх процесів apache буде менше, з левовою часткою запитів буде справлятись Nginx.
Перейдемо до конфігурації.

1) Встановлюємо Apache (чи щось інше що буде у вас бекендом) та nginx з усіма запропонованими залежностями.

2) Конфігуруємо Nginx, щоб він слухав стандартний 80-порт і віддавав всю статику напряму, якщо буде запрошено динамічний контент  - запит буде відсилано Apache-y.

cat /etc/nginx/nginx.conf

# Використовуємо користувача від якого працює сервер Apache
user www-data;
# Кількість дочірніх процесів, обирають за к-тю ядер CPU
worker_processes 4;
worker_rlimit_nofile 8192;

# Місцезнаходження логу помилок і pid-файлу
error_log /var/log/nginx/error.log;
pid /var/run/nginx.pid;

events {
  worker_connections 1024;
  use epoll;
  accept_mutex off;
}

http {
  server_names_hash_bucket_size 64;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  access_log /var/log/nginx/access.log;
  sendfile on;
  tcp_nopush on;
  keepalive_timeout 65;

  # Опції reverse proxy
  proxy_redirect off;
  proxy_set_header Host $host;
  proxy_set_header X-Real-IP $remote_addr;
  proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

  # Опції gzip компресії.
  gzip on;
  gzip_http_version 1.0;
  gzip_comp_level 6;
  gzip_min_length 0;
  gzip_buffers 16 8k;
  gzip_proxied any;
  gzip_types text/plain text/css text/xml text/javascript application/xml application/xml+rss application/javascript application/json;
  gzip_disable "MSIE [1-6]\.";
  gzip_vary on;

  # Включення додаткових конфігураційних файлів
  include /etc/nginx/sites-enabled/*.conf;
}

пʼятницю, 21 грудня 2012 р.

Syslog-ng для централізованого збирання логів


Рано чи пізно постає питання про збирання логів всієї купи серверів, що у вас, у одному місці. І причин, щоб саме так зробити, є декілька: по-перше, так зручно, по-друге, - так безпечніше, адже логи будуть зберігатись в декількох місцях (як мінімум в двох). Коротше кажучи, якщо ви вже читаєте цю статтю - то ви маєте знати навіщо це вам.

Перейдемо до суті. Налаштування проводилось на двох тестових віртуальних машинах:

centos1 - 192.168.1.23
centos2 
- 192.168.1.24

Тому на кожну із них встановлюємо syslog-ng. В CentOS це робиться наступним чином:

# yum install syslog-ng

Нехай centos1 буде головним syslog-ng сервером, що буде слухати 514-й порт, приймати всі логи і розкладати куди-треба. Centos2 буде відправником логів на перший сервер.

Конфігураційний файл syslog-ng на centos2, тобто відправника логів:

# Опис джерела всього потоку логів, що власне нас цікавить.
source s_all {
  internal();
  unix-stream("/dev/log");
  file("/proc/kmsg" program_override("kernel: "));
  file("/var/log/dmesg");
};

# Описуємо які саме файли потрібно буде відсилати. Перед відсиланням до 
# кожної рядка логу буде додано назву демона, який його відіслав 
# (за допомогою опції 'program_override').
source mysqld_log { file("/var/log/mysqld.log" program_override("mysqld")); };
source httpd_log { file("/var/log/httpd/error_log" program_override("httpd")); };

# Описуємо місце/сервер куди будуть відправлятись файли
destination remote { udp("192.168.1.23" port(514)); };

#Найголовніша частина: куди саме і які будуть відсилатись логи.
log { source(s_all); destination(remote); };
log { source(mysqld_log); destination(remote);};
log { source(httpd_log); destination(remote);};

Конфігураційний файл syslog-ng на centos1, тобто сервера, що ці логи прийматиме:

# Описуємо джерело логів - сервер мережі.Тобто логи, котрі прийшли на порт syslog-ng.
source s_udp { udp(ip(0.0.0.0)); };

# Описуємо фільтри. Параметр match означає, що обирати з усього потоку повідомлень 
# лише рядки з указаним значенням
filter mysqld { match("mysqld" value("MESSAGE")); };
filter httpd { match("httpd" value("PROGRAM")); };

# Місце куди будуть зберігатись логи.
destination df_remote { file("/var/log/remote/$HOST.other.log"); };
destination mysqld_log { file("/var/log/remote/$YEAR.$MONTH.$DAY/mysqld.log" owner("root") group("root") perm(0640) dir_perm(0750) dir_group("root"));};
destination httpd_log { file("/var/log/remote/$HOST.apache.log"); };

# Власне сам процес логування - це комбінація всіх вищезазначених параметрів.
log { source(s_udp); destination(df_remote); };
log { source(s_udp); filter(mysqld); destination(mysqld_log); };
log { source(s_udp); filter(httpd); destination(httpd_log); };

Тобто, все відбувається наступним чином:

1) Хост centos2 відправляє логи (всі системні логи+mysqld логи+apache логи) на centos1. Перед відправкою логи httpd помічаються значенням, що стоїть у параметрі program_override. Тобто кожен запис логу mysqld.log помітиться словом mysqld, відповідно httpd.log - словом httpd.

2) Логи, відіслані сервером centos2 приходять на centos1 і починають сортуватись. Всі логи загальні підуть в /var/log/remote/$HOST.other.log,а логи httpd та mysqld за допомогою директиви match будуть сортуватись в окремі папки.

Ну власне все, всі питання або зауваження пишіть в коментарі.

Посилання:
https://wiki.archlinux.org/index.php/Syslog-ng

неділю, 16 грудня 2012 р.

Налаштування MySQL-реплікації типу Master - Master (Slave)

Власне налаштування  реплікації серверів баз даних - дуже важлива складова будь-якого High Load проекту. Надіюсь, що ця невеличка замітка допоможе комусь в освоєні даної теми,  або ж принаймні нагадає мені певні деталі з часом.  :)



Тож до справи!
Для початку опишимо певні деталі. Будемо вважати, що сервера мають такі айпі:

centos1 - 192.168.1.23
centos2 - 192.168.1.24

Редагуємо /etc/my.cnf сервера centos1. Додаємо до вже існуючих параметрів такі:

[mysqld]
# Номер сервера, що реплікується. У кожного має бути унікальний id.
server-id = 1

# Конфігурація сервера, як майстра. Указуємо, де будуть зберігатись бінлоги. 
# Бінлог - це список SQL-запитів (окрім SELECT та SHOW запитів ), що були виконані на сервері задля подальшої їх передачі на слейв.
log-bin = /var/lib/mysql/mysql-bin

# Конфігурація сервера, як слейва. Relay-log - лог дій, котрі були виконані на слейві за ініціативи майстра.
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
#База, що буде реплікуватись.
replicate-do-db = dbwordpress

Для сервера centos2 необхідно прописати ідентичні параметри, окрім значення 'server-id' (змініть цифру наприклад на 2).
Рестартуємо mysql на кожному сервері.