Рубрики
Наследие

Технология повышения качества виртуального хостинга

Как можно повысить качество виртуального хостинга при ограниченном бюджете

Прежде всего, необходимо выяснить, кому необходим качественный виртуальный хостинг и какие стороны делают его качественным именно для данной аудитории.

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

Таким образом, аудитория будет находиться в диапазоне, где максимальная месячная цена за хостинг не будет превышать аренду выделенного сервера (X), а месячная сумма потерь за время недоступности сайта (Y) не должна превышать среднеарифметический месячный доход такой компании (Z).

Следовательно, аудитория расположена в диапазоне Z > Y

Рубрики
Старье

Plesk — собираем все бэкапы на один сервер

Предположим, что у нас есть несколько серверов с панелью управления Plesk. Необходимо организовать систему резервного хранения на одном выделенном сервере, предположим, backup.com

Прежде всего создадим пользователя на backup.com, который будет выполнять процесс резервного копирования, например, backup:
adduser backup
passwd backup

После этого необходимо создать 2048-битный dsa ssh ключ, с помощью которого пользователь backup с сервера backup.com будет заходить на остальные сервера за резервными копиями:
ssh-keygen -b 2048 -C 'Backup' -f .ssh/identity -t dsa
Теперь у нас будет 2 файла — приватный .ssh/identity, который будет сохранен только у пользователя backup, и публичный .ssh/identity.pub, содержимое которого необходимо добавить на остальные сервера в файл .ssh/authorized_keys.
Затем создаем у пользователя backup файл .ssh/config со следующим содержимым:
Protocol 2,1
Host *
User root
Compression yes
ConnectionAttempts 10
KeepAlive no
CheckHostIP no
VerifyHostKeyDNS no
IdentityFile /home/backup/.ssh/identity

после чего необходимо выставить на него права доступа 600 (chmod 600 .ssh/config), и теперь пользователь backup с сервера backup.com может зайти на другие сервера по ssh без ввода пароля как root.

Первая часть готова, теперь необходимо сделать скрипт, который бы автоматизировал процесс. Создадим список серверов в файле list, каждое имя хоста в отдельной строке:
server1.com
server2.com
и т.д.
Затем при помощи следующего скрипта будем обходить список, создавая для каждого сервера отдельную директорию и помещая туда backup, нарезанный кусками на 1G — так их будет удобнее потом забрать по ftp:

#!/bin/sh
cd ~
for i in `cat list`; do
echo $i backup begin
[ -d $i ] || mkdir $i
cd $i
ssh $i '/usr/local/psa/bin/psadump -f - --nostop' | split -b1000m -d - $i.
cd ..
echo $i backup end
done

Рубрики
Старье

Конвертация php-скриптов в статику и отдача с помощью nginx

Предположим, у Вас есть сайт, созданный при помощи php-скриптов и базы данных MySQL. В определенное время сервер перестает нормально работать, так как перегружен посетителями — слишком много запросов.
Как быть? Искусственно ограничить запросы — это значит отбросить посетителей. Наращивать мощности сервера накладно. Оптимизировать скрипты нет времени.
Именно в таком случае поможет тотальная конвертация всего сайта в статический HTML код и отдача его при помощи nginx.

Прежде всего необходимо определить дискретность, с которой происходит обновление информации (допустим, раз в час) и выполнять зеркалирование сайта при помощи команды wget:
wget -m -q -k http://мой.домен/
После этого полученное зеркало синхронизируем с директорией, откуда файлы обрабатывает nginx (предположим, что это /usr/local/html):
rsync -tgu --delete --force мой.домен /usr/local/html
После чего осталось синхронизировать те файлы, которые wget не отзеркалит, например, *.js — java скрипты:
rsync -a --include '*/' --include '*.js' --exclude '*' /путь/к/файлам/сайта/ /usr/local/html/
Это все. Теперь осталось запускать этот код каждый час (или реже) и всю нагрузку возьмет на себя nginx.
Для того, чтобы сохранить доступ к админке CMS, необходимо повесить какой-то поддомен сайта на реальный IP и обращаться к нему.

Рубрики
Наследие

Используем qemu для создания qVDS

Многим хотелось бы иметь на своем сервере возможность для экспериментов без риска или установить другую операционную систему. Конечно, такие технологии существуют уже достаточно давно — VDS, когда на основе одного физического сервера создаются несколько виртуальных.
Однако существует недостаток — необходимо пересобрать ядро с разного рода патчами, что очень рискованно — сервер может не загрузиться с новым ядром.
Для решения этой проблемы мы воспользовались qemu — открытой системой эмуляции как на уровне «железа», так и на UML (только для Linux, естественно).
Однако основным существенным преимуществом на практике является то, установка qemu чрезвычайно проста и не требует пересборки ядра, достаточно распаковать бинарный архив, добавить недостающие библиотеки и qemu готов к работе.

В то же время существуют два серьезных недостатка. Первый — это чрезмерное потребление ресурсов в эмуляции на уровне полной системы, что не позволяет конкурировать на данном уровне с такими технологиями, как OpenVZ, а второй — эмулятор использует GUI, что делает работу с ним чрезвычайно неудобной, особенно, если у Вас к серверу слабый канал.
Но есть возможность избежать этого, запустив qemu в режиме терминала. Мы подготовили два образа: один — мини-образ Linux Debian в состоянии режима basic setup, второй — уже предустановленную FreeBSD с предусмотрительно поднятым ssh-сервером. Пароли также предустановлены — для admin — admin и для root — root. Обязательно смените их сразу после запуска. Скачать архивы с образами и скриптами можно по ftp — ftp://dedic.ru/qemu/, а можно выполнить самостоятельно.

Для дистрибутивов Linux необходимо скачать ISO-образ дистрибутива, и лучше всего, если это будет mini-образ, остальное можно ставить по сети. Затем этот образ монтируем во временную директорию (опция loop) и забираем оттуда само ядро vmlinuz и initrd.img. Запускаем qemu с этим ядром и inird, а в дополнительных опциях передаем вывод на консоль. После запуска qemu мы работаем с виртуальным сервером через консоль. Естественно, что графический инсталлятор лучше не использовать.

В случае же с FreeBSD все еще проще — достаточно включить в конфигурации comconsole и настроить ее, после чего перенаправить ввод-вывод в stdin/stdout.

Для доступа с виртуального сервера в сеть на настоящем сервере необходимо включить форвардинг:
echo 1 > /proc/sys/net/ipv4/ip_forward
и разрещить выход с подсетки 127.20.0.2 (это IP-диапазон виртуальных серверов):
iptables -t nat -A POSTROUTING -s 172.20.0.0/24 -d 0/0 -j MASQUERADE
Для того, чтобы виртуальный сервер был доступен под одним из реальных IP реального сервера, необходим обратный проброс:
iptables -A FORWARD -d 172.20.0.2 -i eth0 -j ACCEPT
iptables -t nat -A PREROUTING -d реальный.ip.тут -p tcp -j DNAT —to-destination 172.20.0.2