13 октября 2007 в 23:20
Вот, говорят, если проект подрос - бери под него VPS! А вот ничего подобного 
Впервые я попробовал VDS на firstvds.ru. Ну просто оболдел от возможностей, которые дает свой, пусть и небольшой сервер. Но потом эйфория быстро прошла и начались проблемы с нехваткой памяти. А памяти, как обычно, нехватало для базы.
Тогда я попробовал один финт, который мне понравился и который я сейчас ищу возможность воплотить в более глобальном масштабе. От старого виртуального хостера остались пароли к базе данных, работавшей на отдельном сервере, причем хостер позволял удаленно коннектиться с любого хоста. Я переключил базу на него... и - о чудо! - сайт стал грузиться в разы быстрее!
Я убрал со своего малыша-VDSа Апач, заменив его на ниндзю nginx'а, освободив при этом 50% оперативки (с учетом запущенных 3-х процессов PHP-FastCGI) и зажил в счастьи, пока старый хостер не обрубил доступ к базе
Так вот и подумалось мне. Можно было бы собирать хостинг по частям: маленький VPSик только для nginx'а и статики за 5 долларей, метров 200-500 под базочку MySQL у другого хостера, FastCGI-сервер - у третьего, memcached-хост - у четвертого. Так получилась бы (получилась бы?) высокопроизводительная распределенная вычислительная система, да еще и с возможностями резервирования для повышения отказоустойчивости, которые дает nginx.
Вот у мастерхоста есть конструктор тарифов. Там можно галок натыкать и навыбирать опций себе. Но там в базовый комплект таки входит Apache 
Ну не нужен он мне! Дайте мне только MySQL на быстром серваке и все!
Можно ли осуществить мою мечту, собрав по крупицам все самое лучшее с разных хостов? Существуют ли только MySQL-хостинги или только FastCGI или только memcached? Может кто встречал такое? (а может у кого и так просто портец 11211 для всех открыт нашару - заходите, люди добрые! У меня, кстати, открыт
Комментарии
И при отказе любого хостера валится либо сервак, либо пхп, либо бд. Замечательно
Плюс к тому, надо, чтобы коннект между серваками быстрый был)
По-моему это не особо хорошая идея
Вы знакомы с nginx? Я говорил о резервировании. При отказе одного из бэкендов сервер автоматом берет данные с "живого" или с локального. Отвалился MySQL - данные берутся с memcached-сервера. Отвалился memcached - из локального статического кэша. Какова вероятность отказа всех трех систем сразу, а?
К тому же у хорошего хостера валится все достаточно редко. Да и сидят они все в принципе на одном канале 
По крайней мере можно таких подобрать.
В целом же я говорю о системе, которая будет по мощности и надежности превосходить выделенный сервер, а стоить в разы дешевле. У хостеров, между прочим, система устроена именно так. Покупая виртуал, Вы фактически берете три разных сервера (+/- 1 - у всех по-разному).
С nginx я знакомлюсь
В любом случае, удачи вам
Отпишитесь о результатах, интересно
Отчасти о результатах я уже писал
См. строку с "о чудо!" 
Передача базы данных на своеобразный аутсорсинг другому хосту дает ощутимый результат по быстродействию в разы по сравнению со своим VPS: тяжелый запрос на своем хосте выполняется 2 сек, на удаленном - 0.02 (выделенного сервера у меня пока никогда не было, сравнить не могу, да и цель у меня - уйти от покупки выделенного сервера путем создания вычислительной сети по кускам).
особенно от мастерхоста
- все что угодно можно ждать...
Неправы вы, дешевле оно никак не получится. Иначе все бы давно так и хостились.
Версии-то поди не самые последние, bugfix'ы-то и патчи хостеры ставят только после того, как их взломают 
А затраты будут на:
1) Проверку, живы ли все элементы распределённой схемы по различным критериям
2) Синхронизацию данных между ними ("Отвалился MySQL - данные берутся с memcached-сервера. Отвалился memcached - из локального статического кэша."). У вас есть уже готовые наработки, как эти данные в РАЗНЫХ форматах быстро синхронизировать? Причём во всех направлениях (н-р, MySQL -> memcache и обратно, статика - и обратно)
3) Для обеспечения быстрого переключения ВСЕ компоненты ВСЕГДА должны быть online. Не замучаетесь поддерживать всё это в боеготовности, хоть и на shared-хостинге? Хотя тут как раз VPS нужен, можно что-то автоматизировать через cron, дополнительные левые программы и скрипты свои.
4) Ну и про security подумайте: где у вас там MySQL открытый наружу? Memcache? IP подскажите?
Вот и выходит цена за чистый хостинг немногим меньше (но не факт, учитывая необходимую сложность хостинга), а геморррооооооююююю (затраты на развёртывание и поддержку) будет гораздо больше, в разы.
Всё вместе это называется "Полная стоимость владения" (экономисты, поправьте, если не прав в терминологии)
VLAD_X, а Вы знакомы с nginx?
Первые три пункта уже встроены в него, плюс модуль друпала для поддержки memcached сам начинает работать с базой, если memcached-сервер отвалился.
MySQL наружу открыт у многих крупных хостеров, проблем с безопасностью нет, если все нормально настроено. У memcached, конечно, надо только через файрволл жестко задавать ip, которым он доступен.
Вот и выходит что надо просто правильно настроить конфиг nginx и все завертится
Ну никак у меня не получяется 400$ в месяц, даже если в "полную стоимость владения" включить затраты на электроэнергию и аренду беговой дорожки для профилактики люмбаго 
1. VPS - 5$ от firstvds.ru
или отдельный VPS - 20$
Берем отдельный VPS за 20$ и забиваем все 512Мб (хотя в России такой не взять. Будет метров 192-256)
2. MySQL - 9$ от любого виртуала
3. FastCGI - бывает такое? Если нет, то входит в стоимость п. 2.
4. memcached - уж точно не бывает
Итого: ~ 55$
при этом MySQL работает на двухпроцессорном монстриле, который сам по себе дешевле 400$ не взять, FastCGI выделяет хоть все 50Мб под один PHP-процесс, ну и метров 200 memcache - вполне неплохо для кэширования динамических данных на плотно посещаемом проекте.
За эти же 55$ даже полуразвалившийся селерон выделенный с трудом найти можно, не говоря о том, как он будет работать.
Все так хоститься не могут, т.к. на форексе тоже не все торгуют и спутники в космос не все запускают. Это решение для тех, у кого не стоит главным критерием скорость ответа суппорта.
С nginx'ом ОЧЕНЬ ХОРОШО знаком.
1) nginx никак не умеет определять, жива ли БД на каком-то там хосте. Всё, что он может - это перебирать memcached'ы round robin или по списку.
Теперь вопрос: вы планируете держать одну и ту же информацию в неск. memcached-серверах и mysql-серверах? Ведь нехорошо показывать пользователям что-то за прошлую неделю, а что-то - за эту, в случае падения чего-то в вашей распределённой системе.
А уж если вы хотите содержимое БД вынести в виде статики ещё на один сервер.....
2) "MySQL наружу открыт у многих крупных хостеров, проблем с безопасностью нет, если все нормально настроено."
Наивный вы человек. Для развенчания своих мифов: http://bugtraq.ru/, http://www.securitylab.ru/vulnerability/, http://securityvulns.ru/
То, что вы пытаетесь сделать, называется кластеризацией и применяется как для увеличения надёжности/сохранности данных, так и для ускорения доступа к ним.
Но о кластеризации начинают думать тогда, когда просто покупка нового сервера не спасает ситуацию.
В вашем случае можно попробовать MySQL Cluster, если не боитесь открывать БД MySQL наружу.
Схема может быть такая
VPS1: nginx + все файлы (статика и сам Drupal)
VIRTUAL1: Apache+PHP + все файлы (Drupal)
Файлы на VPS1 и VIRTUAL1 должны быть идентичны в рамках установки Drupal'а, т.к статику (типа /sites/all/modules/bla-bla-bla/script.js) должен отдавать nginx, а /index.php и /sites/all/modules/bla-bla-bla/bla-bla-bla.module должен обрабатывать Apache+PHP
Таких VIRTUAL'ов можно несколько и nginx'ом раскидывать запросы между ними, НО необходимо их часто синхронизировать на уровне файлов.
VPS2: MySQL Cluster (manager, который раскидывает запросы к БД). Судя по беглому обзору, у него неслабые системные требования
VIRTUAL2...n: те самые, выставленные наружу, БД MySQL, к которым запросы приходят от менеджера кластера.
В деньгах выигрыш получится не особый, по сравнению с покупкой мощного VPS или железного выделенного сервера, но геморрою вы себе наживёте.
Ссылки:
http://www.mysql.com/products/database/cluster/
http://www.opennet.ru/cgi-bin/opennet/ks.cgi?mask=web%20cluster%20apache...
http://xpoint.ru/forums/computers/dbms/mysql/thread/39928.xhtml
http://xpoint.ru/forums/computers/dbms/misc/thread/24954.xhtml
http://xpoint.ru/forums/computers/os/unix/thread/8524.xhtml
http://www.webmascon.com/topics/technologies/4a.asp
http://www.osp.ru/lan/2000/05/131142/
http://www.osp.ru/os/2003/05/183030/
P.S. Ради проекта с посещаемостью меньше неск. тысяч уников в день, БД меньше неск. гигабайт и рассчитанным только на Россию (или на любую другую ОДНУ страну) я бы не стал заморачиваться.
В случае с MySQL + Drupal эффективней не кластеризация, а репликация - для Drupal 6 есть патчи.
Да, и ещё: всё это желательно развернуть у одного хостера, чтобы не проблем проблем с доступностью компонентов системы.
Ну или в одном ДЦ, но чтобы все связи были прямые, а не через Европу/Штаты. Сейчас такое бывает, слышал у некоторых.
vlad-x про безопасность отлично сказал, даже добавить нечего. Я тут озаботился установкой/настройкой grsecurity, а народ предлагает запросы через инет гонять
500 меторов под базу за "9$ от любого виртуала" ню-ню...
думаю на такое мало хостеров приличных согласится
думаю лучше приличный вдс брать где-то за 30-50$ или 90-100$ дедик если проект стоит того.
Думаю стабильности и производительности от от предлагаемого не будет.
(тот же мускул на 10% в среднем быстрее пашет через сокеты чем через порт)
VLAD_X, понимаю, Вы профессионал (сразу видно), но больно Вы усложняете. Задача у меня не собрать кластер, а собрать систему более производительную и за меньшие деньги. Так сказать, от бедности. Синхронизации для простого проекта никакой не нужно. Во всех хранилищах хранятся разные оперативные данные. При отказе одного из хранилищ данные не теряются, а всего-лишь падает быстродействие системы (memcache не работает - берем из БД).
Конечно, простым проектом я называю не хомяка, а сайт с довольно мудреной бизнес-логикой, но с малым количеством хостов. До 1000. Т.е. миллионов он не приносит, но ресурсов требует много. К примеру, если это какой-либо спец. поисковик, то роботы должны постоянно кружиться и насиловать CPU. При этом сам сайт не работает в принципе! Оставив на хосте-контроллере роботов и nginx, а другое распихав по другим машинам можно резко изменить картину в гораздо более положительную сторону.
Конечно, надо спорить уже в каких-либо рамках конкретных проектов. Я говорю о проектах, которые на начальном этапе развития могут тратить не более 50$ на хостинг.
В PS Вы указали, что не стали бы заморачиваться для ру-проекта с маленьким трафом. А мне приходится заморачиваться, т.к. перейдя с VPS-а 512Мб оперативки за 35$ (это ответ Т0р'у), на котором сайт жутко медленно работал из-за БД, на трехсотрублевый виртуал от Мастерхоста, мой сайт прибавил в скорости из-за хорошей БД, но начал вываливаться из-за ограничений в 16Мб для PHP. Так вот и появилась у меня мысль - взять все самое лучшее от разных хостов.
Спасибо за ссылки, но несколько неприлично с Вашей стороны бить по морде интеллектом заведомо менее осведомленного оппонента
Вот теперь картина становится более ясной.
Вы выбираете Microsoft-way: "Если что-то тормозит - надо улучшать железо"
Возможности классической оптимизации вы уже исчерпали?
* nginx'у отдаём статику, всё остальное - проксируем на Apache
* Apache и PHP компилим с минимумом модулей, урезаем до 2-3 процессов
* eAccelerator для PHP с 16-32 Мб кэшем в памяти (прикидочно из расчёта 512Мб ОЗУ всего). Если php-файлы меняются исключительно редко, то можно отключить в нём проверку времени модификации и всё будет браться из памяти.
* Аналогично собираем по минимуму необходимого MySQL и долго затачиваем его, глядя на SHOW STATUS, slow_log и mysql_result (перловая программка, которая красиво показывает чего и сколько было к БД). Собственно, в MySQL'е нужем query_cache от 16Мб (здесь и далее все цифры прикидочные, реальные можно получить только опытным путём, как описано выше), join_buffer и кол-во открываемых и хранящихся в памяти таблиц. ИМХО, это самые определяющие скорость параметры.
Раз вас грузят работы, значит медленно отдаются странички для анонимусов.
* Включаем cache или даже agressive_cache в Drupal'е, можно попробовать кеширующие модули boost, fastpath_fscache и т.д. Но я сам их не пробовал, поэтому ничего конкретного сказать не могу.
* Ещё раз читаем slow_log, делаем EXPLAIN запросов из него и проверяем использованием индексов. Если индекса нет - создаём его, если есть. но не используется - добавляем FORCE INDEX(имя_индекса) к нужному SQL-запросу.
Некоторые модули грешат (грешили?) отсутствием индексов как таковых впринципе.
Отступление: некоторое время назад именно FORCE INDEX() и индексирование вообще позволило резко увеличить производительность одного из моих сайтов. В дальнейшем я просто положил все модули в Git (система контроля версий типа SVN/CVS) и на всех сайтах они обновляются автоматически; не приходится каждую копию модуля на каждом сайте патчить вручную.
)
Сейчас БД этого сайта разрослась до миллиона записей, но самым слабым местом остаётся PHP. Ведь если верить модулю devel, на обращение к БД при генерации странички уходит 20-30 ms, а сама страиница собирается в итоге за 0,5-2 секунды.
Упирается всё в объём памяти для кэширования PHP (да, у меня тоже небольшая ВПСка для этого сайта
Руки дойдут, будет время - озадачусь перетаскиванием всего этого на colocation. т.к. оптимизироваться дальше уже почти некуда.
* Ещё полезно положить в /etc/cron.daily/ вызов myisamchek, который будет проверять, восстанавливать, оптимизировать и сортировать БД.
Огромное спасибо за, прямо-таки, мануал
У кого что тормозит? Ай-да ко мне в блог! 
До этого я думал, что исчерпал все возможности оптимизации
- Апач снес вообще. Вместо него PHP в режиме FastCGI
- nginx на статику
Вот eAccelerator'ом я не баловался - так и не дошли руки. И MySQL так глубоко не оптимизировал, хотя видел, что некоторые друпал-девелоперы вообще без индексов пишут модули. Но у меня в основном все с индексами.
Если бы было еще время заниматься такой глубокой оптимизацией
Про роботов Вы не поняли. Грузят CPU мои собственные роботы (на сокетах памяти едят минимум, но зато CPU максимум), которые необходимы для сбора данных с других сайтов (котировки всякие, новости и т.д.) - но это, конечно, частный случай. Не все своих роботов гоняют. Да и я своих по уму не должен на веб-сервере держать, а опять же - выносить отдельно!
Ну вот сами посудите, что мне проще сделать: сидеть до бесконечности отслеживать статсы запросов в базу и крутить ручки или просто прикупить доступ к ней на виртуале (или еще где), где местные админы итак ее донельзя уже заоптимизировали?
У меня была база в 5 млн (или даже 10 млн) записей. После того, как запрос с одним JOINом выполнялся у меня минут 20, я плюнул на это хозяйство и перелил базу прочь с VPS'а.
В идеале, конечно, надо И оптимизировать софт до упора, И оптимизировать железо, также до упора. И то и то.
Все обязательно ляжет! А должно пахать 
Я, также, считаю, что у системы должен быть обязательно запас прочности. Т.е. нельзя впихивать систему тютелька в тютельку, освобождая каждый метрик памяти. Вдруг на сайт какая-нибудь Вебальта в 50 потоков накинется или кто-нибудь о сайте на Digg напишет
слишком много траффа перекачивать придется с базы на сервер с нгинкс