Каким должен быть идеальный виртуальный хостинг (в том числе и для Drupal 7)

Как сказал кто-то из великих:

Идеала достичь невозможно, но стремиться к этому нужно.

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

Фантазировать буду, безусловно, со своей колокольни: у нас в агентстве для своих нужд виртуальный хостинг уже давно не используется, мы сначала перешли на VDS, а потом и на выделенные железные серверы. Соответственно, для собственных и регулярно поддерживаемых клиентских проектов — вопрос с хостингом решён так, как нам нравится и кажется правильным (dedicated). Но к нам довольно часто обращаются за разовой поддержкой клиенты со стороны. И тогда мы отправляемся покорять чужие виртуальные хостинги от самых разных провайдеров. Подобные визиты часто оканчиваются печалью.

На этот пост меня спровоцировал мой любимый трижды лучший сотрудник месяца компании Мастерхост — Иван (знакомьтесь, фоловьте):

Речь перед этим твитом зашла о лютых ограничениях на «Мастерхосте», с которыми мы недавно столкнулись, пытаясь завести на упомянутом хостинге сайт, построенный на базе Drupal 7. Вообще, «Мастерхост» — это лишь яркий пример и достойный повод, странных хостеров — хватает и без них. Далее перечислю наиболее типовые странности хостеров, мешающие жить и работать.

Старый и ограниченный серверный софт

Ужасный пример старьёвщиков — caravan.ru. У них на виртуальном хостинге работает PHP 5.2.4. Кстати, даже на нём можно завсети Drupal 7, но только  с бэкпортированном патчем безопасности htmlspecialchars. А они его не ставят. В итоге пришлось в очень странных позах сношаться с этим хостингом, патчить ядро Drupal`а, в результате чего сайт там всё-таки завести удалось.

Но, внимание, кроме этого на Караване не получилось запустить PDO, т.е. MySQL у нас как бы отпал из возможных технологий, и пришлось в качестве основного хранилища использовать SQLite. Кстати, оказывается, что это ни так уж и фатально: административный интерфейс конечно тормозит, но закешированный фронт-энд сайта работает вполне сносно. Голь на выдумки хитра, в общем.

Слишком мало ресурсов для PHP и слишком жёсткие лимиты

Тут на сцену выходит masterhost.ru со своими скудными 32 МБ памяти на скрипт. С одной стороны, тут можно выступать: не используйте монстров в виде тяжёлых CMS, тогда вам и 32 метров хватит. Для Drupal 6 — этого вполне хватает. Для седьмой версии — уже нет. Притом ситуация такая: для большинства типовых операций этой памяти хватает и в Drupal 7, но когда, например, начинает шуршать Imagecache (который теперь в ядре), гоняя библиотеку GD, то, всё, память заканчивается. В процессе массовых операций через queue (а такое случается с Drupal 7 сразу при установке), скрипт вообще валится с ошибками в духе:

[warn] [client IP] CPU limit exceeded (X %)
[warn] [client IP] IO limit exceeded (X)

«Мастерхост» предлагал решение:

Можете сменить версию РНР на 5.3, где для работы РНР выделяется 64МВ памяти.

Но и тут есть подвох: версия PHP изменится для всей площадки, т.е. если на неё уже кроме нового сайта на Drupal 7 (обожающим PHP 5.3) крутится ещё и какое-нибудь самописное старьё не способное пережить переход с 5.2 на 5.3 без нотисов, то старью придётся туго.

Возможно, допустим такой финт: всё площадку перевести на PHP 5.3, а для старья руками собрать PHP 5.2 через cgi (это «Мастерхост», к его чести, раньше сделать точно позволял). Но пробовать не стали, ибо лимиты по CPU и IO всё равно могли бы остаться узким местом.

На виртуальном хостинге лимит быть обязаны. Это понятно и не оспаривается. Но лучше, чтобы они срабатывали не столь жестко. Грамотно лимитирование реализовано у spaceweb.ru — они следят за аккаунтом и умеют присылать примерно такую табличку:

+------------+-------+-------+-------+-------+
| Date       | Load  | Quota | Warn  | Err   |
+------------+-------+-------+-------+-------+
| 2012-07-14 |   5,36|    72%|      6|      0|
| 2012-07-13 |   6,11|    72%|      9|      0|
| 2012-07-12 |   7,18|    72%|     12|      0|
| 2012-07-11 |   6,21|    72%|      8|      0|
| 2012-07-10 |   5,65|    72%|      3|      0|
| ...        |       |       |       |       |
| 2012-07-01 |   8,14|    73%|     16|      0|
+------------+-------+-------+-------+-------+

Warn — это предупреждения. В идеале, их быть не должно, но если их мало, то вас не блокируют, пока не приспичит. Err — это жесткие превышения, которые могут оборачиваться уже 50x ошибкой. Если у вас на аккаунте таких будет много, то вас пригласят на более дорогой тариф (собственно, такие приглашения следуют от всех хостеров при превышении).

Что такой подход означает на практике?

  1. Во-первых, изредка превышать лимиты вы можете вообще без последствий, например, когда что-нибудь устанавливаете, или когда у вас отрабатывает планировщик.
  2. Во-вторых, если у вас ресурс планомерно развивается и начинает жиреть в плане трафика, то вы «по табличке» заранее сможете заметить тенденцию и переезд на более серьёзный тариф запланировать самостоятельно. То есть резко вас не отключат (если не DDOS или не Хабраэффект).
В общем, считаю, что лимиты по процессору и I/O должны быть мягкими, а памяти на скрипт, по сегодняшним меркам, надо давать по умолчанию хотя бы 64 МБ (а лучше — 96 МБ, этого даже для экспериментов с GD на больших картинках хватит).

Отсутствие SSH-доступа

Если вас не пускают по SSH на сервер, то вы не сможете, например, залить большой дамп базы данных через консоль. Придётся обращаться в саппорт.

Но это не самое страшное: даже такие типовые операции, как удаление всей диретории сайта к чертям для перезаливки по новой через FTP занимает куда больше времени, чем выполнение команды rm -r ~./dir в консоли.

Без SSH вы не сможете нормально наладить процесс резервного копирования на независимый хост, придётся извращаться.

Без SSH вы не сможете пользоваться такой удобной штукой для Drupal как drush.

Я мог бы продолжить, но, пожалуй, остановлюсь, назову лишь виноватых — infobox.ru не даёт доступа по SSH. Не даёт и SFTP/FTPS, т.е. вы вынуждены гонять пароли и данные по открытым каналам (а ведь иногда даже своему провайдеру доверять не стоит).

Нетрадиционный доступ к логам

Уточню, что традиционным я считаю подход, когда логи лежат где-нибудь в ~/mysite, а корень сайта направлен на ~/mysite/public_html. На мой взгляд, access- и error-логи каждого виртуального хоста на виртуальном хостинге должны храниться отдельно для каждого виртуального хоста.

Это позволяет, например, дать разработчику доступ к ~/mysite по FTP, не давая доступ ко всему аккаунту (и, тем более, к панели управления). При этом разработчик сможет отлаживать сайт, смотреть на серверные ошибки и не сможет смотреть, например, на трафик остальных виртуальных хостов аккаунта.

Камень со свистом летит снова в огород «Мастерхоста» — у них error-логи можно смотреть только через панель.

Вялая техническая поддержка

Тут ругать буду jino.ru. Попросили у тех. поддержки ftp-логи в четверг, а в среду получили ответ о том, что логи за требуемый период предоставить, увы, невозможно.

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

Но совсем ужасно то, что отвечали на вопрос почти неделю (6 дней), притом что вроде бы вопрос был задан типовой. Или никто и никогда не спрашивал у них ftp-логи?

Невозможность редактирования DNS-зоны

Тут обсуждать нечего. Хотите подключить Яндекс Почту для доменов или Google Apps — надо поправить MX. Хотите временно перенаправить домен на запасной сервер (например, на время деплоя) — надо сменить A-запись. В общем, масса типовых операций требует простого контроля над зонами.

А вот, например, zenon.ru позволяет их редактировать только по письму в тех. поддержку. Плюс их система поддоменов не позволяет вообще сменить A-запись для @.

Родная веб-почта у них, кстати, вообще никакая, т.е. судьбой предначертано каждому пользователю «Зенона» уходить на Google Apps или Яндекс ПДД.

Вместо итогов

Я понимаю, что пост из разряда:

Ругать всегда проще.
Критикуешь — предлагай.
А чего добился ты?
Если ты такой умный, то почему строем не ходишь?

И так далее…

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

Более того, скажу, что у перечисленных хостеров кроме упомянутых недостатков, есть иные важные преимущества, ради которых, быть может, им стоит всё остальное прощать. Например, jino.ru — позволяет докупить к своему аккаунту виртуального хостинга memcached, чего я ни у кого больше не встречал.

Чтобы пост вдруг не превратился в рекламный, никого тут рекомендовать не посмею, но виртуальные хостеры кажущиеся мне идеальными — есть. Перечисленным же выше ребятам просто есть куда стремиться в их ближайшем развитии. От души и без всякой иронии, желаю им удачи на тернистом пути к идеалу.

4 комментария

  1. Дархан
    Авг 21, 2012 @ 22:29:12

    Большой дамп базы можно залить, например через sypex dumper.

    Reply

    • kostin
      Авг 21, 2012 @ 22:54:28

      К сожалению, и это не решает проблемы сразу на 100%. Потому что для коннектов с юзерского окружения на ряде хостингов встречаются лимиты по количеству запросов в секунду, объёму транзакции и т.д. Это преодолимо, но приходится извращаться. Быстро не вспомню у кого была такая фигня, но, не исключено, что даже у кого-то из перечисленных хостеров.

      До кучи к Sypex`у порекомендую свой любимый однофайловый http://www.adminer.org/

      Reply

  2. Nina
    Сен 04, 2012 @ 18:49:05

    Иностранные хостинги по деньгам запрашивают меньше, а дают больше.)

    Reply

  3. Oleg
    Май 05, 2013 @ 00:36:15

    Мне лично SSH удобно, но я стараюсь обходить стороной хостинги, которые предоставляют их… из-за юзеров-соседей, которых пичкают шелами по этим же ссх. Был уже случай с баном ip хостера из-за соседей, а пострадал и я. По поводу друпал, то memory_limit конечно решает. Держу своих 2 единственных друпальчика на http://adminvps.ru — после последнего неудачно опыта с хостером искал того, где больше всего памяти. Эти ребята дают 512 мб + cp выше крыши, ну и пхп 5.3

    Reply

Leave a Reply

*