Хостобзор. Хостинг в Иркутске (PHP)

О чём речь

Обычно под хостингом понимают предоставление места для ваших HTML (PHP) страниц на веб-сервере. Совокупность ваших HTML страниц (и сопутствующих им картинок), связанных общим начальным (доменным) именем (например, apache.org), принято называть веб-сайтом. Второй существенной составляющей определения хостинга (которую часто пропускают) следует считать привязку доменного имени к папке вашего сайта. Потому что мало поместить файлы на веб-сервер, надо чтобы пользователи Интернета могли обратиться к вашему сайту по его законному (доменному) имени; для этого владелец хостинга должен записать имя вашего домена в настройках своего веб-сервера.

(1) Иногда люди привязывают два доменных имени к папке одного сайта. Например, чтобы их легче было найти (по разным вариантам): belon.irk.ru и belon.irkutsk.ru.

(2) Чаще бывает так, что на одном хостинге расположено несколько сайтов одного владельца, и к каждому из них привязано одно доменное имя.

(3) Можно подключиться к сайту и совсем без доменного имени, по ip-адресу – такой доступ обычно используют для внутреннего пользования. У нас как раз в Деловой неделе используется такой доступ для сотрудников, уехавших временно на дачу, – они набирают в браузере не имя, а адрес http://ttk.ir2.ru/, заходят в нужный раздел и делают свою офисную работу, не отходя от грядки с морковкой.

Мы даже поместили было на собственный хостинг в офисе часть своих сайтов, но наш интернет-провайдер Сибирьтелеком оказался не в состоянии обеспечить заявленную им скорость и устойчивость соединения. Ну, и тогда мы начали искать нормальный коммерческий хостинг – качеством получше и ценой подешевле.

Качественный хостинг

Методика определения подходящей цены для хостинга примерно такая же, как и для помидоров: надо узнать цену 10-ти разных продавцов, вычислить среднюю и уменьшить её на 30%. С качеством всё обстоит намного сложнее. В двух слова не объяснишь, надо на примерах.

0. После недолгих поисков услуг хостинга в Гугле вы неизбежно попадаете на сайт hostobzor.ru – там сосредоточено наибольшее количество предложений, которые можно изучать с помощью удобной системы поиска (отбора вариантов). Мы поставили системе поиска задачу: не менее 100Мб на диске стоимостью не более 100р. Предложений – куча!

1. Юридический аспект. Первая, самая простая, проблема заключается в надёжности вложения денег: вы платите чёрт знает кому за тридевять земель, через какие-то электронные кошельки; и что если деньги у вас возьмут, а взамен ничего не дадут? Отсюда острое желание работать с поставщиком услуг, физические координаты которого (не говоря уже о телефоне!) известны; то есть пропускаем сайты хостеров, на которых из координат есть только электронная почта.

2. Всего сразу не учтёшь, даже подробно изучив прайс хостера и отзывы клиентов на сайте Хостобзор (если такие есть). Услуга хостинга достаточно сложна, включает в себя много разных параметров, оценка которых часто меняется (сегодня не будет хорошим то, что было хорошо вчера). Поэтому вторым по важности условием является вменяемость техподдержки, – да, не надо суперзнатоков, надо чтобы хотя бы просто на любой ваш вопрос, даже самый (с их точки зрения) глупый, вам быстро (в течение часа-двух) отвечали, и чтобы в ответе проявлялось намерение вам помочь (даже если оно не очень потом реализуется).

Этот этап отбора отсеял для нас 3-4-х хостеров: мы задавали им перед заключением договора некоторые простые вопросы о параметрах mysql-php их серверов, и если реакция чем-то настораживала (скоростью ответа, пренебрежением, нежеланием обсуждать "несущественные" проблемы), диалог с нашей стороны прекращался навсегда.

***

По итогам проверок по этим двум параметрам (которые от страха заслонили нам своей значимостью все остальные параметры) мы так же неизбежно, как на сайт Хостобзор, попали на хостинг gudzonhost.ru (это было 3 года назад). Позже стало ясно, что с некоторыми параметрами нам там просто повезло, и если бы мы их заранее учитывали, всё равно бы выбрали этого хостера. Параметры это вот какие: к своему дисковому пространству можно привязывать неограниченное количество доменов (то есть создавать сколько угодно сайтов); базы данных mysql не учитываются при подсчёте занимаемого места на диске (то есть можно создать сайт из нескольких килобайт скриптов, которые буду извлекать из баз данных сотни мегабайт текстов и файлов) – и всё это на 200Мб места за 32 доллара в год.

Однако в течение первого же года работы выяснился главный недостаток Гудзонхоста – удалённое расположение дата-центра (в США). Возникает, например, проблема – сайт недоступен. Пишем в техподдержку. Они отвечают: "А что такого? у нас небольшие плановые работы, скорость ответов сервера несколько замедлилась". Это у них там, в Штатах она "замедлилась", а у нас это выглядит так, будто доступ совсем пропал.

3. Вот тут-то мы и научились обращать внимание на следующие параметры – близость сервера к Иркутску и скорость ответа сервера. Они связаны, конечно, друг с другом, но проверяются именно по отдельности, двумя разными командами под Windows (про Линукс не пишем, с ним и так работают грамотные специалисты): кнопка Пуск – Выполнить – "tracert 91.189.82.157" и Пуск – Выполнить – "ping 91.189.82.157".

Это ip-адрес хостинга, где расположен сейчас сайт dn.ir2.ru. Надо вводить именно адрес, на котором (будет) расположен ваш сайт, а не адрес сайта хостера, потому что они могут располагаться в совершенно разных точках планеты. Это порождает ещё один обязательный вопрос хостеру перед заключением договора: "На каком сервере (ip-адрес) будут располагаться мои сайты?"

Выполните указанные команды, и посмотрите, как должны выглядеть нормальные ответы на них.

>ping dn.ir2.ru
Обмен пакетами с dn.ir2.ru [91.189.82.157] по 32 байт:
Ответ от 91.189.82.157: число байт=32 время=100мс TTL=59
Ответ от 91.189.82.157: число байт=32 время=119мс TTL=59
Ответ от 91.189.82.157: число байт=32 время=95мс TTL=59
Ответ от 91.189.82.157: число байт=32 время=133мс TTL=59
Статистика Ping для 91.189.82.157:
  Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
  Минимальное = 95мсек, Максимальное = 133 мсек, Среднее = 111 мсек

>tracert dn.ir2.ru
Трассировка маршрута к dn.ir2.ru [91.189.82.157]
с максимальным числом прыжков 30:
  1    <1 мс    <1 мс    <1 мс  192.168.1.1 
  2    29 ms    28 ms    28 ms  213.228.116.148.ncc.sibirtelecom.ru [213.228.116.148] 
  3    27 ms    26 ms    28 ms  213.228.118.121.ncc.sibirtelecom.ru [213.228.118.121] 
  4    58 ms    68 ms    62 ms  ge-0-0-0.nsk-bsr1.ncc.sibirtelecom.ru [213.228.117.178] 
  5    58 ms    61 ms    57 ms  81.176.209.49 
  6   114 ms   112 ms   110 ms  217.106.1.150 
  7   114 ms   116 ms   454 ms  217.106.1.150 
  8   114 ms   111 ms   115 ms  kurchatov.oc-corp.ru [91.189.82.157] 
Трассировка завершена.

У gudzonhost.ru ответы выглядят намного хуже (вы можете проверить результаты трассировки для разных серверов самостоятельно или на сайте Хостобзор.ру):

>ping gudzonhost.ru
Обмен пакетами с gudzonhost.ru [74.200.80.101] по 32 байт:
Ответ от 74.200.80.101: число байт=32 время=336мс TTL=53
Ответ от 74.200.80.101: число байт=32 время=281мс TTL=53
Ответ от 74.200.80.101: число байт=32 время=375мс TTL=53
Ответ от 74.200.80.101: число байт=32 время=300мс TTL=53
Статистика Ping для 74.200.80.101:
  Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
  Минимальное = 281мсек, Максимальное = 375 мсек, Среднее = 323 мсек

>tracert gudzonhost.ru
Трассировка маршрута к gudzonhost.ru [74.200.80.101]
с максимальным числом прыжков 30:
  1    <1 мс    <1 мс    <1 мс  192.168.1.1 
  2    27 ms    28 ms    26 ms  213.228.116.148.ncc.sibirtelecom.ru [213.228.116.148] 
  3    29 ms    28 ms    25 ms  213.228.118.121.ncc.sibirtelecom.ru [213.228.118.121] 
  4    26 ms    26 ms    29 ms  ge-1-0-0.irk-br1.ncc.sibirtelecom.ru [213.228.118.102] 
  5    26 ms    28 ms    25 ms  87.226.232.153 
  6   150 ms   150 ms     *     so-2-0-0.frkt-ar1.msk.ip.rostelecom.ru [87.226.139.10] 
  7   151 ms   148 ms   151 ms  de-cix.he.net [80.81.192.172] 
  8   156 ms   158 ms   154 ms  10gigabitethernet1-4.core1.ams1.he.net [72.52.92.94] 
  9   166 ms   165 ms   173 ms  10gigabitethernet1-4.core1.lon1.he.net [72.52.92.81] 
 10   258 ms   262 ms   263 ms  10gigabitethernet6-3.core1.ash1.he.net [72.52.92.137] 
 11   251 ms   249 ms   251 ms  209.51.161.10 
 12   253 ms   248 ms   252 ms  r01.iad.keepitsecure.net [69.65.112.1] 
 13   309 ms   256 ms   260 ms  aggr-sw2.iad.defenderhosting.com [69.65.112.94] 
 14   251 ms   250 ms   251 ms  eqashd53.keepitsecure.net [69.65.115.216] 
 15   252 ms   251 ms   249 ms  host.alaskahost.net [74.200.80.101] 
Трассировка завершена.

Ну, а когда они ещё и повысили цены (долларовые!), наше решение сменить хостера приняло необратимый характер. Тем более, что мы к тому времени уже целый год экспериментировали с хостингом d-host.ru – переход на него получился очень плавный.

d-host был (и, надеюсь, будет) несколько необычный хостинг. Экономичный: нужно платить не за фиксированное место, а ровно за то, которое занимает ваш сайт. Правда, место, занимаемое базой данных, при этом учитывается. Стоимость в итоге получилась примерно такая же, как на Гудзонхост (до наценки), а скорость ответа сервера намного лучше (он в Москве, а не в Америке). Недостатки: отсутствие панели управления хостингом. К счастью, ко времени перехода на него мы перестали нуждаться не только в панели управления, но даже и в Phpmyadmin'е – все работы стали делать своими собственными скриптами (тексты которых приведём в конце статьи). Единственная задача, которую мы не могли решить сами, – привязка доменов к папкам; но эту задачу всегда оперативно решали хозяева по первому нашему письму, даже наш кириллический домен в виде эксперимента привязали к своему серверу.

Вообще d-host был весь какой-то "неформальный": некоторые параметры mysqld не давали нам работать, мы попросили изменить их – и их изменили (на многих "формальных" хостингах удавились бы из-за любой мелочи). Видимо, из-за своей "неформальности" у них и возникли проблемы – сервер был дискредитирован использовавшими его хакерами и в дальнейшем уничтожен вирусными атаками (надеюсь, не железо:-), и нам срочно пришлось искать новое место.

4. d-host не выдержал проверки следующего важного качества хостинга – надёжности. Оно включает в себя бесперебойную непрерывную работу сервера (что обеспечивается, в частности, дублирующими механизмами) и ежедневное резервное копирование всей информации пользователей (backup). Ну, резервное-то копирование там, положим, было, но использовать его данные теперь всё равно можно только на другом хостинге.

5. Следующий кандидат был отвергнут нами из-за ограничений по трафику – он всем был хорош, но трафик (суммарный размер открытых посетителями страниц и картинок) 3Гб в месяц для наших сайтов (если собрать 3-4 в одном месте) является опасной границей (мы близки к её переходу), за которой началось бы вымогательство дополнительной оплаты.

***

Динохост мы уже проверяли раньше, но отвергли по каким-то причинам. В этом году то ли цены у них стали ниже, то ли у нас взгляд на какие-то вещи изменился, но dinohost.ru нас вполне устроил. 99р. за 150Мб в месяц – вполне приемлемо. Ограничения – 3 домена на одну учётную запись (то есть именно за те же 99р.) и 3 базы данных mysql – выглядят плоховато, но не фатально. В конце концов нам несложно запихать всю информацию не только в три, но даже и в одну базу данных, кому хуже-то будет – только mysql-серверу. Ну, а что касается доменов, так там ещё 3 паркованных разместить можно, а это почти то же самое, что и дополнительные, если подойти к делу с умением (о чём в следующем разделе).

Техподдержка там вполне разумная, помогли нам с правильным названием русской локали в PHP (раньше мы как-то всегда обходились простым "ru_RU", а тут, оказывается, всё усложнилось: "ru_RU.cp1251"). Причём, решение подсказали не с первого письма, то есть видно, что кто-то там с кем-то советовался, искал для нас ответ.

Хостинг в Иркутске

Мысль найти хостинг прямо в родном городе, конечно, давно нас посещала. И мы как-то даже начали вести переговоры с одной компанией, но потом оказалось, что у неё только представитель в Иркутске, а дата-центр (компьютеры) то ли в Голландии, то ли в Швейцарии, и в добавок предоставляют они только выделенные серверы (целые компьютеры в аренду), что намного дороже того, что нам требуется для наших небольших сайтов.

А тут недавно, в начале апреля, прямо в наш каталог сайтов irweb.ir2.ru кто-то поместил ссылку с названием «Хостинг в Иркутске» (на ловца и зверь!). Ну, и мы, радостно кликнув по ссылке, попали прямо на сайт hosting.alleanza.ru – в Новосибирске. Новосибирск, конечно, не Иркутск, но уже совсем тепло:

>ping gost.vostsibspravka.ru //(один из наших новых проектов)
Обмен пакетами с gost.vostsibspravka.ru [81.176.214.84] по 32 байт:
Ответ от 81.176.214.84: число байт=32 время=57мс TTL=57
Ответ от 81.176.214.84: число байт=32 время=70мс TTL=57
Ответ от 81.176.214.84: число байт=32 время=66мс TTL=57
Ответ от 81.176.214.84: число байт=32 время=54мс TTL=57
Статистика Ping для 81.176.214.84:
  Пакетов: отправлено = 4, получено = 4, потеряно = 0 (0% потерь),
Приблизительное время приема-передачи в мс:
  Минимальное = 54мсек, Максимальное = 70 мсек, Среднее = 61 мсек

Хостинг Альянза, по первому впечатлению, оказался очень забавным. Во-первых, испугало то, что подключение там не автоматическое (написано, что, мол, после оплаты пишите нам по почте и просите подключить). А плата была вдобавок сделана через расчётный счёт, – ну, мы подумали вообще долго ждать придётся. Однако на другой день после оплаты в ответ на отправленное нами письмо с номером П/П без всяких проблем и задержек был получен доступ к новенькой учётной записи!

Дальше пошли какие-то мелкие проблемы (куда без них при переезде), ошибки с привязкой доменов, которые техподдержка быстро исправила. И даже согласились изменить кое-какие критичные для нас настройки PHP, прямо как неформалы на d-host. Панель управления там какая-то туповатая (Direct admin), но нам она не очень-то и нужна.

Неприятной неожиданностью (впрочем, не такой уж тяжёлой, учитывая плату 60р. за дисковое пространство 300Мб в месяц!) для нас оказалось отсутствие дополнительных доменов. В прайс-листе строчка о количестве доменов на одну учётную запись выглядит весьма двусмысленно: "Доменов (алиасов) 5", о дополнительных доменах отдельной записи нет (правильнее было бы указать, что их в данном тарифном плане "0"). Автор этой статьи на них за это наругался, накричал в письме, а они в ответ его рассмешили, написав, что обязательно учтут все пожелания в дальнейшей работе. Ну-ну, посмотрим... Гм, уже действительно учли (http://www.hosting.alleanza.ru/hosting-pack-17.html):

Доменов на разные папки (мультидомены) [ i ]  	1
Доменов на одну папку (парковки, алиасы) [ i ] 	5

Но зато и цена у них за время нашей недолгой переписки выросла с 60р. в месяц до 85! Быстро работают. Но всё равно, ограничение по количеству доменов нам кажется совершенно неразумным. По нашему мнению, для хостера имеют смысл лишь ограничения, препятствующие перепродаже хостинга (например, количество доступов по ftp, пользователей mysql).

А пока пришлось изворачиваться, прикручивать паркованные домены к отдельным папкам на сервере через mod_rewrite Apache'а, мучать лишними редиректами себя и сервер хостера – добавив в файл .htaccess примерно следующие инструкции (для работы в качестве отдельного сайта gost.vostsibspravka.ru, папка которого gost расположена внутри основного сайта):

RewriteEngine On
RewriteBase /
RewriteCond %{HTTP_HOST} ^gost\.vostsibspravka\.ru$
RewriteCond %{REQUEST_URI} !^/gost
RewriteRule ^(.*)(\/?)$ gost/$1$2 [L]

***

Возвращаясь к заголовку раздела, нужно сказать, что хостинга собственно в Иркутске как не было, так до сих пор и нет. Нельзя же всерьёз рассматривать предложения с баснословным ценами Сибирьтелекома или 20Мб по стыдливо спрятанной мутной цене на серверах ДСИ.

PHP-скрипты для обмена данными с хостингом

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

Общая идея такова. На одной учётной записи хостинга находится несколько сайтов, каждый сайт в своей папке, вложенной в одну общую папку: Общая папка (Первый сайт, Второй сайт, Пятый сайт ...). В Общей папке (в которой лежат все сайты) у нас находится и общий скрипт конфигурации – confogbase.php (подключаемый к другим скриптам через инструкцию include), в нём записаны некоторые важные переменные, такие как:

$pathacc – физический адрес «базовой папки», в которую вложены сайты
$prefixbd – префикс, добавляемый к каждой нашей базе данных хостером

Если физический адрес определить несложно с помощью, допустим, встроенной константы PHP __FILE__, то префикс базы данных определяется тупым перебором всех накопленных за обозримое время хостеров – по каким-то уникальным строкам в пути к файлу:

if (false!==strpos($pathacc,"home/ir2")) $bdprefix="ir2_";
else if (false!==strpos($pathacc,"ir2netru")) $bdprefix="ir2netru_";
else if (false!==strpos($pathacc,"borona")) $bdprefix="borona_";
else $bdprefix="";

Надо собрать куда-то все файлы из всех папок хостинга, упаковать, и отправить через ссылку для скачивания. Один вариант – в zip-архив (точнее, .tar.gz). Но мы предпочли таблицы Mysql – из-за некоторых дополнительных удобств вроде сравнения дат файлов с эталонной таблицей (для разностного копирования). То есть все файлы запихиваются в таблицу mysql, потом формируется sql-запрос содержимого таблицы, пакуется в gzip и выдаётся пользователю как один файл. При приёме на другом хостинге этот файл распаковывается и выполняются записанные в нём sql-запросы; затем из таблицы mysql на новом хостинге файлы (тем же принимающим PHP-скриптом) выгружаются в соответствующие папки.

SQL-запрос, помещающий отдельный файл в таблицу, выглядит примерно так:

insert into `table1` values ('полное_имя_файла', 'дата_файла', 'текст_файла');

Если с именем файла и датой всё вроде бы понятно, то в тексте файла сплошь и рядом встречаются символы ";" (точка с запятой) в конце строки. А это недопустимо, так как данная последовательность используется в Mysql для разделения отдельных запросов. Мы знаем три способа решения этой проблемы, и используем и[ в зависимости от ситуации. Самый тупой и надёжный способ – кодировать тексты файлов с помощью функции PHP bin2hex(): $str="0x".bin2hex($str); – в этом случае важно не заключать полученные значения в кавычки в sql-запросе. Этот способ мы обычно используем, когда загружаемый файл и sql-сервер находятся на одном компьютере. Если требуется пересылка данных на удалённый хост (скачивание), bin2hex мы не используем, чтобы не увеличивать размер файла; используем в этом случае оба оставшихся способа:

1) $str = addcslashes($str,"\"\'\r\n\0\t"); (экранирование концов строк и нулей);

2) наш собственный, ещё более тупой (а значит и надёжный) способ – добавление специальной последовательности символов для разделения sql-запросов (а то кто его знает, что мы ещё там забыли заэкранировать). В этом случае надо, конечно, сначала удалить эту специальную последовательность из обрабатываемой строки. Или заэкранировать в строке один из входящих в последовательность символов (например, табуляцию, как у нас).

В результате код отправляющего с хостинга файлы скрипта получился таким: код файла scriptsallout.php. А вот код принимающего скрипта: код файла scriptsallin.php, – он выводит на экран форму, в которую нужно ввести (краткое) имя файла с данными. Файл (у нас он при скачивании получает имя scriptsall-dino.sql.gz) следует сначала скопировать в ту же папку на хостинге, где лежит данный скрипт.

Последняя деталь. Как видно из текста обоих скриптов, файлы .htaccess и php.ini не скачиваются и не закачиваются вместе со всеми – чтоб нечаянно не испортить (не перезаписать) существующие, которые могут видоизменяться в зависимости от настроек конкретного хостинга.

О выгрузке-загрузке баз данных с одного хостинга на другой мы расскажем как-нибудь в другой раз. Попозже.

© 2009, «Деловая неделя», Михаил Гутентог

Читать все комментарии (2)

Добавить комментарий:

*Автор:
E-Mail:
*Текст: