Итак, тормоза «нагнули» сервак — поисковые роботы и прочая нечисть создаёт очень нехилую нагрузку, с которой в последнее время серваку справляться всё труднее и труднее, а последние дни сообщения о недоступности сайтов просто поставили вопрос ребром.
Специфика некоторых моих проектов это несколько тысяч справочных файлов, и всё это реализовано на связке nginx + apache.
После изучения нескольких хороших статеек (в конце поста приведу ссылки) и неудачной попытки задействовать кэширование NGINX (разбираться с этим не стал, т.к. нашел более правильное решение проблемы) я понял, что самые тормоза — из-за allow override индейца! без которого реврайты htaccess не работают. Собственно, при любом обращении к сайту индеец перечитывает всю файловую структуру — а это с моими тысячами файлов — полная засада. Умножаем количество запросов на несколько десятков в минуту — получаем ступор всего сервака.
Единственное правильное решение — переход на fastcgi, в лице php-fpm, который не обрабатывает htaccess (при этом все правила переносятся «руками» на уровень фронтенда т.е. nginx сервера).
Правда и тут не без подводных камней — немного пришлось переписать движек сайтов т.к. реврайт nginx-a несколько другой по сравнению с реврайтом на htaccess в плане передачи заголовков php.
Тут большое спасибо ребятам с форума php.ru за помощь в моей ветке.
При обработке текущего положения нужно использовать ТОЛЬКО параметр REQUEST_URI — остальные, по крайней мере у меня, не передаются! вернее передаётся фактический обработчик index.php

После перехода на Fast-CGI страничка начала отдаваться где то в 20 раз быстрее, и нагрузка на сервер спала пропорционально. Сообщения о недоступности сайтов сошли на нет.

Цель достигнута!

Хорошие статейки:
Почему NginX с Fast-CGI быстрее, чем Apache с mod_php?
Попытка номер раз создать почти идеальный htaccess
Один конфиг Nginx для работы с кучей разных сайтов
Установка nginx, php-fpm и mysql на CentOS
ngin+php-fpm делаем веб-сервер под высокую нагрузку

Отдельно выделю очень хорошую статью на счёт кэширования nginx
у меня вроде завелось, но почему-то через часок другой, решение падало — может файла слишком у меня много — незнаю, но статья отличная — факт.

Прозрачное кэширование в nginx для всех и каждого

P.S. Ещё 2 проблемы было — не передавался GET в несуществующий php и не уходила почта
первое решилось добалением $is_args$args; в try_files
try_files $uri /index.php$is_args$args;
второе — указание sendmail_path в php-fpm.conf (сразу там до кучи путь для сессий поправил)

Итак, имеется виртуальная машина Bitrix под VMWare на которой хотелось бы докинуть 8 Гигабайт под системный раздел.

Первое — добавим нужные гигабайты на диск непосредственно в гипервизоре и перезагрузим машину, далее нужно перераспределить место непосредственно в CentOS.

Начальная ситуация
df -B G

fdisk -c -u /dev/sda команда p

Будем делать вручную, используя fdisk удалим существующий раздел и создадим на его месте новый, требуемого размера. Для этой операции не надо размонтировать раздел, не надо загружаться с rescue образа, данные файловой системы также не будут утеряны. Мы просто перепишем одну строку в таблице разделов, после перезагрузки CentOS примет ее к сведению. (оригинал статьи для типа раздела раздела 8E — Linux LVM)

Запускаем fdisk -c -u /dev/sda, вводим команду p — в моём случае нужно изменить раздел sda3 (третий по порядку)
Удаляем его командой d
Создаём новый командой n (при создании система сама предложит правильные начальный и конечный сектора)
Записываем таблицу разделов командой w выходим q и перезагружаем ОС.

В моём случае тип системы ext4 — поэтому после перезагрузки просто расширяем файловую систему на всё доступное свободное пространство командой resize2fs /dev/sda3

Вуаля

Итак — настроил файловую синхронизацию по RSYNC — запихал в скрипт — всё синхронизится, всё устраивает.
Сам скрипт поставил в крон и успокоился… а зря !
Оказывается скрипт по времени запускался, но сама синхронизация нет!!!
В итоге разборок получилось, что переменные окружения при запуске через CRON для пользователя не подгружаются!
Соответственно, система не находила rsync и скрипт не работал!!!
Прописал абсолютные полные пути — всё завелось, с пол-пинка.
Я с подобной проблемой уже сталкивался при отправке писем php скриптом по крону — и снова те же грабли 🙁
Внимание и контроль!
Внимание и контроль!
🙂

Итак, первый шаг для создания «горячей копии» виртуальной машины, физически расположенной на другом сервере — файловая синхронизация сделана (5 раз в сутки думаю достаточно) — см. предыдущий пост.
Второй шаг для достижения цели — онлайн репликация MYSQL баз данных.
(преследуемая цель: если первый сервер умирает — перебиваем IP в запасной виртуалке, выключаем slave в MYSQL и вуаля — с минимальными затратами во времени и без потерь поднимаем рабочий сервер).

Сразу оговорюсь, что физические сервера у меня находятся в одной физической сети — соответственно я назначил каждой виртуалке свой IP адрес сети класса С/24 192.168.100.ххх
Практически всю информацию для репликации я взял из статьи

НА МАСТЕРЕ добавляем в конфиг my.cnf секция mysqld и рестартим mysql

server-id = 1
log-bin = /var/lib/mysql/mysql-bin
replicate-do-db = testdb

Далее, несколько запросов в БД (сбрасываем кэш, блокируем таблицы)
flush logs;
reset master;
FLUSH TABLES WITH READ LOCK;
SET GLOBAL read_only = ON;
show master status;
Бэкапим данные для переноса на слейв + переписываем название файла и циферку (то, что show master status выдал)
Разблокируем таблицы
SET GLOBAL read_only = OFF;
UNLOCK TABLES;

НА СЛЕЙВЕ правим конфиг и рестартим mysqld
server-id = 2
relay-log = /var/lib/mysql/mysql-relay-bin
relay-log-index = /var/lib/mysql/mysql-relay-bin.index
replicate-do-db = testdb

Выполняем MYSQL запросы (название файла и позицию берём из show master status на мастере)
CHANGE MASTER TO MASTER_HOST = «192.168.1.101 «, MASTER_USER = «replication «, MASTER_PASSWORD = «password «, MASTER_LOG_FILE = «mysql-bin.000003 «, MASTER_LOG_POS = 98;
start slave;

Проверяем как пошло
show slave status;

Лично у меня какие то дубликаты всплыли при первой синхронизации, что недавало дальше синхронизировать
для решения проблемы добавил slave-skip-errors = 1062 в конфиг

Если нужно заново стартануть — делаем всё тоже самое, но на слейве сначала нужно выполнить
stop slave;
flush logs;
CHANGE MASTER TO ….
start slave;

Проверим «руками» — правим значение в какой нить таблице на мастере, смотрим изменилось ли на слейве.

P.S.
Немного о ‘подводных’ камнях:
Настраивал на виртуалках с 2мя разными средами (FreeBSD, CentOS) — на каждой столкнулся с проблемой видимости порта 3306 извне, поэтому некоторые моменты:
* iptables
* для диагностики на мастере netstat -ln | grep mysql
* для диагностики со слейва на мастер telnet master 3306
* комментируем bind-address на мастере
* комментируем skip-networking на мастере
* ну и следим за синтаксисом, логинами и паролями 🙂 (ошибся в пароле в CHANGE MASTER TO … — долго парился пока заметил)

P.P.S
О контроле размера бинарных файлов тут http://forum.hostdvor.com/viewtopic.php?p=132
я поставил SET GLOBAL expire_logs_days =2

Итак, развивая поставленную перед собой задачу по созданию горячей резервной копии виртуальной машины я начал с файловой синхронизации.
Сначала решил задачу в лоб — ищем изменённые через find -mtime — пакуем, закидываем на фтп, в нужном месте разворачиваем.
Но, потом обратил внимание на специализированный для этих задач софт — утилита rsync.
На серверах с сайтами, для которых необходимы горячие резервные копии устанавливаем rsync в качестве демона через xinetd, не забыв поставить его в автозагрузку.
Настраиваем конфигурационные файлы, запускаем, проверяем слушает ли демон 873й порт ‘netstat -lnpt |grep 873‘
Вносим его в iptables (я делаю это интерактивно webmin-ом) — проверяем удалённо либо телнетом ‘telnet x.x.x.x 873‘, либо сразу запросив rsync-ом список ресурсов ‘rsync x.x.x.x::‘
Для настройки всего этого дела я использовал две отличные статьи
http://likeunix.ru/centos-rsync-backup/
http://www.stableit.ru/2010/04/rsync.html

Повторяться с настройками не буду, лишь хочу обратить внимание на некоторые настройки:
в настройки демона, файлы не подлежащие сжатию я добавил jpg картинки, т.к. они и так сжаты по формату
dont compress = *.gz *.tgz *.zip *.z *.rpm *.deb *.iso *.bz2 *.tbz *.jpg *.JPG *.jpeg

в скрипте для исключения «мусора» использовал опции —exclude «*/temp/*» —exclude «*cache/*» —exclude «sess_*» —exclude «*.log» —exclude «*.gz» —exclude «*.zip»
для синхронизации удалённых файлов —delete —delete-after

backup_date=»$(date +%d.%m.%Y)»
backup_filename=»$(date +%d.%m.%Y)_backup_filename»

cd /patch/to/dir/
tar -czvf — —exclude=www/photo —exclude=www/uploads —exclude=’*.zip’ —exclude=’*.jpg’ ./www/ | split -b 1999m — ./$backup_filename.tar.gz

Итак, одна из моих виртуальных машин поднималась на FREEBSD и так оказалось, что размер диска под систему был выбран слишком маленьким.
Добавить гигабайт в VMWare не проблема — а вот дальше, не тривиально:
Итак, винт ЗАБЭКАПИЛИ, расширили, далее:
gpart show
ругается на винт — CORRUPT
gpart recover da0
gpart show
уже лучше — свободное место видим, НО разбивка не позволяет объединить корневой раздел с этим свободным местом из-за SWAP
я решил под SWAP вообще отдельный виртуальный винт создать и скинуть его туда полностью
сказано, сделано — вырубаем VM, ADD HDD, врубаем
размечаем новый винт и создаём на нём раздел под своп
sysinstall, fdisk, label
далее переключаем систему на работу с этим свопом — правим /etc/fstab ребутим систему
смотрим top — ага, размер рабочего свопа совпадает с выделенным — значит всё ОК
далее проще — нужно убить слайс со свопом и расширяем корень на свободное пространство
ребут, идём в single режим
убиваем слайс со старым свопом gpart delete –i3 da0
пробуем растянуть корневой слайс gpart resize –i2 da0
облом, требует параметр ядра поправить
правим sysctl kern.geom.debugflags=16
gpart resize –i2 da0
ура!
правим назад sysctl kern.geom.debugflags=0
далее нужно расширить файловую систему
growfs -y /dev/da0p2
df не видит свободное место
fsck -yf -t ufs /dev/da0p2
а вот теперь всё ОК!

В продолжении предыдущего поста, ещё полезная команда (при работе с большими файлами)
Разбить файл «кусками» по 700 мегабайт

split -b 700m archive.tar part

Собрать обратно

cat part* > archive.tar

Перетаскиваю довольно крупный проект — в сжатом виде >40 Гб.
Даже физически файлы перетащить — по времени половина дня уйдёт.
Пока перетащил, настроил, потестил — уже заново нужно перетаскивать в силу произошедших на сайте изменений.
Вот тут то и пригодится очень полезная команда, вернее связочка, добавляющая в архив только файлы созданные/изменённые за последние N дней


find . -type f -mtime -10 -print0 | xargs -0 tar -cjf archive.tar.bz2


В закладки, полезняшки и т.д. однозначно!

P.S.

ВНИМАНИЕ — на рабочем проекте у меня такая связка даёт сбой!!! думаю из за ограничения на длину данных передаваемых xargs

такая конструкция вроде пашет


find . -type f -mtime -10 -print0 | zip archive.zip @


ещё экспериментирую с параметром -n в xargs — пока безрезультатно

P.S.S.
Спасибо большое drBatty за помощь в решении проблемы в ветке форума

всё правильно: xargs режет список аргументов дозами по несколько сотен..тысяч имён файлов. Дальше у вас записано «tar —create» что значит «создать архив». Он и создаётся несколько раз. Вы наблюдаете только последний вариант.

Если вы хотите делать обязательно так, то вам следует использовать —append, которая не работает для сжатых файлов, потому вам следует ещё потом сжать, как в третьем варианте.

А вообще мне понравился вариант с промежуточным файлом — сначала выдёргиваем в файл все файлы find-ом, потом уже скармливаем его tar-у

#!/bin/bash
set -x
TMP=$(mktemp)
find -mtime -10 >$TMP
tar —create —files-from $TMP
rm —force $TMP

Всем привет!

В конторе вчера слёг основной канал, ну ничего думаю — для этого существует резервный!
А резервный тоже лежит! и думается мне ужо не первый день. Сцуко 🙁

Скрипт контроля в крон ежечасно!
Сам крипт такой:


#!/bin/bash
HOSTS="IP1 IP2 IP3"
# Количество запросов
COUNT=3
for myHost in $HOSTS
do
count=$(ping -c $COUNT $myHost | grep 'received' | awk -F',' '{ print $2 }' | awk '{ print $1 }')
if [ $count -eq 0 ]; then
# 100% failed
echo "$myHost offline" date|mail -s "$myHost is offline" mail@gmail.com
echo "$myHost offline" date|mail -s "$myHost is offline" 7913xxxxxx@sms.mtslife.ru
echo "$myHost offline" date >> check_ip.log
fi
done


P.S.
Скрипт отправляет СМС на МТС только в случае если на номере включена услуга mail-to-sms (услуга бесплатна).