HTS.RU
(495) 363-33-10
(800) 100-46-78
Skype: HTS-RU

www.  

КОРЗИНА
Услуги Акции Партнерская программа
О компании Поддержка Документы Контакты

Почему выбирают нас?


10 дней бесплатно для тестирования услуг

Домен при заказе хостинга в подарок

Скидки до 15% при оплате от 6 месяцев

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

Дарим хостинг и домен при покупке CMS

Желающим уйти — возвращаем деньги

Бесплатный перенос сайта с другого хостинга

Хостинг адаптирован под системы


Хостинг — это...

Многие, начинающие пользователи сети интернет рано или поздно приходят к вопросу «А что такое хостинг?».
В этой статье мы ответим на этот вопрос и опишем стандартные решения Хостинга, которые существуют на данный момент, а также расскажем о том, как это устроено в нашей компании ЗАО «Хостинговые Телесистемы» www.hts.ru

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

Услуги Хостинга можно разделить на:
  • Виртуальный Хостинг (или просто Хостинг);
  • Виртуальный выделенный сервер (или VPS, он же VDS);
  • Аренда выделенного сервера.
Чем могут различаться Хостинговые компании, на что стоит обратить внимание при выборе?
  • Очень просто и в то же время сложно ответить на данный вопрос. Обычно для большинства первым фактором является, конечно, цена услуги. Но если изучить этот вопрос, сравнить разные предложения, то в условиях рынка и достаточно большого количества Хостинг-Провайдеров можно прийти к выводу, что цены очень схожи.

  • Хорошим советом будет посмотреть отзывы о Хостинговых компаниях, что думают другие? Отсутствие отзывов показывает, что компания новая, обычно таких обходят стороной. Присутствие только позитивных отзывов тоже настораживает, в среднестатистической компании всегда будут разные мнения, нужно их изучить и попробовать понять, прийти к промежуточному выводу о компании. И после этого задаться вопросом о качестве предоставляемых услуг хостинга, и подходе хостинговой компании к реализации хостинга.

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

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

  • Залогом успеха хостинговой компании является собственный Дата-центр (ЦОД), который укомплектован дорогостоящим оборудованием и отвечает самым высоким современным стандартам качества. Многие компании, не имеющие собственного Дата-центра, арендуют оборудование в крупнейших Дата-центрах Москвы или Санкт-Петербурга. Минусы такой схемы работы в том, что свободный доступ в такие Центры ограничен, и, если что-то сломалось, нужно выписывать пропуск, ехать туда, решать проблему самостоятельно. Все это увеличивает время простоя сайтов, что отрицательно отражается на seo-продвижении и эффективности рекламной кампании или SMM, проводимых в данный период. Соответственно привлекательность предоставляемых услуг виртуального хостинга такими компаниями снижается.

А теперь, давайте рассмотрим технические варианты реализации хостинга.

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


(рис. 1)

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


(рис. 2)

Еще сложнее система, когда все основные сервисы разнесены по отдельным физическим серверам, не мешая друг другу в работе.


(рис. 3)

У всех выше перечисленных систем есть свои минусы и плюсы.
Например, на рис. 1 все находится на одном сервере, удобно администрировать и контролировать, но это также дает и минусы. Предположим, на сервер начинает поступать множество запросов, которое заставляет сервер генерировать динамический контент, причем для создания контента требуется задействовать ресурсы базы данных, так вот в этом случает при плохой разработке может случиться весьма неприятный казус.
Суть его в том, что пришедший запрос на веб-сервер порождает запрос к базе данных, который по разным причинам может выполняться достаточно долгое время, при этом потребляя достаточно большое количество ресурсов системы в целом. И так приходит еще один запрос на веб-сервер, и еще, и еще, в результате сервер работает все медленней и медленней, пытаясь обработать все запросы. В итоге работа всего сервера будет парализована, и даже пользователи, которые запросят контент не связанный с динамической конфигурацией, могут его и не получить из-за перегруженной системы.

Второй вариант (рис. 2) на первый взгляд решает проблемы первого случая, но тут можно получить другую проблему. Как-то в своей практике, я наблюдал работу CMS-системы, которая требовала выполнить около 17000 запросов к базе данных. В связи с тем, что на обработку одного запроса к базе уходило менее 0.01 сек., в сумме это выходило порядка 120-200 секунд, что, в общем-то, совсем не приемлемо. Если страница сайта будет открываться более, чем нескольких секунд, вероятней всего посетитель покинет сайт. На этом примере я показал, что при большом количестве запросов к базе данных, накладные расходы, как бы не заметные в большинстве случаев, вызывают очень большую проблему.
А вот как раз в первом случае (рис. 1) запросы могли бы выполняться раз в 10 быстрей, так как было бы затрачено гораздо меньше сетевых служб, так как запросы проходили напрямую через сетевой стек операционной системы.

Третий вариант (рис. 3) кажется вообще идеалом совершенства, администратору надо контролировать уже три сервера, у каждого из которых могут быть свои проблемы, которые могут повлиять на работу всего комплекса. Хотя конечно уже все лучше, если вдруг вас завалит Спамом, и почтовый сервер не выдержит, сайт(ы) будут работать как и раньше, это им не помешает.

Вы можете подумать, как же легко сделать систему для хостинга сайтов, больших затрат не нужно. В Интернете достаточно много свободных или платных систем управления серверами, которые позволяют не вдаваться в тонкости системного администрирования. Да соглашусь, при небольшом количестве сайтов и не большой активности на них у вас все будет работать штатно, и вы можете спать спокойно.

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

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

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

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

Вы встаете перед выбором, что же делать дальше?
Что делать дальше, это достаточно сложный вопрос, поскольку он завязан, как и на коммерческой части, так и на морально-этической, я думаю это тема отдельной статьи, где можно философствовать над всеми аспектами данного вопроса.

Вернемся же к техническим вопросам. «Что можно еще улучшить?» — спросите вы. В принципе нет предела совершенства, давай для начала разделим вашу систему на две части «front-end» и «back-end» (рис. 4)


(рис. 4)

Все запросы приходят на «front-end» и дальше этим сервером распределяются между остальными «back-end» серверами. Можно подумать какая же это хорошая схема, а на самом деле, что будет, если «front-end» сломается? Правильно, никакое кол-во «back-end» не поможет спасти ситуацию, если нет «front-end» сервера. Значит нужно предусмотреть какой-то альтернативный вариант для такого случая.

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

Кстати, это место достаточно интересное и имеет множество решений.
Как пример, если у вас роутер имеет поддержку WCCP (Web Cache Communication Protocol), то можно использовать его для этих целей. Его суть будет сводиться к тому, что если ваш «front-end» жив и регулярно отвечает на запросы роутера или уведомляет его о своей жизни, роутер перехватывает пакет и направляет его именно на «front-end». Если же связь с «front-end» утеряна, то роутер направляет запросы напрямую на один или множество «back-end», все зависит от вашего желания и типа настроек.

Даже если у вас и нет дорогого роутера, то и тут остается большое поле для действий. Обычный сервер можно превратить в роутер, используя различные системы, такие как ipfw, iptables, pf можно достигнуть похожего результата, я бы сказал даже большего, чем в выше описанном случае. Управлять правилами тут можете вы сами при написании достаточно простых программок. Если же к этому еще и подключить, например CARP (Common Address Redundancy Protocol), то можно сделать дубль такого сервера, в случае выхода из строя одного сервера, работу подхватит другой, тем самым увеличив надежность системы в целом.
Более того, имея вышеперечисленные системы, вам будет проще бороться с такой частой проблемой в последнее время, как DDOS(Distributed Denial of Service). Так как вы не допустите попадания негативного трафика на основные сервера системы, тем самым защитив их.

И опять возник вопрос — «Что можно еще улучшить?»
Да не проблема, давайте возьмемся за почтовую систему, на первом этапе, когда вы еще все только начинали, самое важно не допустить простых ошибок. Например, для всех почтовых протоколов выдать клиентам одно и тоже имя вида mail.domain.ru, все равно же один сервер скажете вы. Но в дальнейшем в случае расширения вам придется сложней разделять это имя по разным протоколам, поэтому не ленитесь, сделайте отдельные имена на разные протоколы: smtp, pop, imap, даже если они пока и ведут на один сервер.

Следующим шагом можно разделить протоколы smtp от pop и imap, причем для большей надежности, можно разделить smtp на два отдельных сервера для входящей и исходящей почты.
Так же с увеличением кол-ва входящих или исходящих сообщений, можно будет увеличивать кол-во серверов smtp. В случае сервера исходящих сообщений можно использовать указание нескольких ip адресов в dns сервере, и тогда по алгоритму round-robin исходящий сервер клиентом будет выбираться по принципу перебора адресов по круговому циклу, тем самым распределяя нагрузку между серверами.

Точно так же можно поступить и с серверами входящей почты, но у вас есть еще один инструмент для управления процессом, куда же доставлять почту идущую на домены ваших клиентов. Этот параметр MX тип записи в dns, который указывает на mail-exchange сервера, которые обслуживают почту для домена. У этого типа записи можно указывать приоритет для каждого сервера или множества серверов, тем самым контролируя в каком порядке и на какой сервер будет доставлено письмо для вашего клиента.

Imap и pop протоколами немного проще, по сути, они должны жить рядом с достаточно большим хранилищем почты, чтобы не лимитировать клиентов размерами ящиков. То есть для этой цели подойдет любой сервер с большими дисками, в дальнейшем конечно лучше использовать raid системы для надежного хранения почты, если вы будете брать с клиентов деньги за это то вы должны обязательно задуматься о надежном хранении.

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

Файловую систему можно вынести на другой сервер, например по NFS, и на нем обслуживать cron задания. Так же на этот сервер можно вынести ssh доступ, так как работа этого сервера не связана с работой основного веб-сервера. Тут можно позволить клиентам пользоваться различными программами, которые вы раньше не позволяли использовать, например различные компиляторы. Ftp нет смысла сюда выносить, все же загрузка файлов должна быть ближе к хранилищу и как правило ftp не вызывает проблем ни по диску, ни по процессору, ни по памяти.

Если стало опять скучно, то можно заняться модернизацией «back-end» серверов.
Чаще всего на таких серверах происходит реконфигурация, дабы не заставлять этого делать, есть несколько путей.
Первый — это создания виртуального мапинга имен сайтов, через пути в файловой системе в которых будет фигурировать имя сайта, но в этом случае крайне сложно будет регулировать настройки определенных сайтов.
Второй вариант, это написание своего модуля который будет динамически создавать и кешировать конфигурацию на основе базы данных. Тут тоже не стоит особо увлекаться, так как если выбрать базу данных mysql или pgsql, можно будет парализовать или их работу или в случае их поломки парализовать работу сайтов, тут лучше использовать или BDB или CDB. То есть использовать промежуточную базу для хранения настроек и обновлять их, если произошли изменения в центральной базе.

Когда вы справились с вышеописанной задачей, то можно выбрать еще что-то.
Давайте подумаем, а как мы можем всем сайтам давать при необходимости отдельный ip адрес. Если у вас не один и не два сайта, а несколько тысяч, то возникает не простая ситуация. Надо прописать все ip к определенным сайтам, весьма не впечатляющее занятие, помимо прописывания в конфигах веб-сервера надо прописывать это и в конфигах самой операционной системы, что даже при некой автоматизации, потом ужасно некрасиво будет выглядеть.

Тут у себя мы выбрали немного другое решение, это создание reverse-proxy c хитрым мапингом, суть его сводится к следующем, на роутере создается маршрут для достаточно большой сети, которая направляется на адрес нашего прокси сервера. На самом проксе сервере, прописывается правило все пакеты идущее к нам в этой сети перенаправлять в определенный порт, причем именно перенаправлять, то есть оставляя в пакетах информацию о src и dst адресе. Дальше наш прокси сервер, получая этот пакет, видит куда он направлен, опять же через промежуточно сформированный CDB файл, и определяет на каком из «back-end» находится контент по данному запросу, направляет этот запрос туда и передает ответ клиенту.

По такой же аналогии можно вообще раздать всем сайтам IPV6 адреса, наверняка в вашей базе, где хранится список сайтов, у каждого сайта есть свой уникальный числовой идентификатор, как правило, это integer, а это всего лишь 32 бита, для ipv6 это сущая мелочь. То есть на все ваши проделки хватит сети /96, 4 млрд. адресов. :-)
Суть идеи такова, пакеты перехватываются и направляются опять же в порт проки сервера, только в этом случае мы берем последние 4 байта адреса ipv6, которые и есть уникальный идентификатор сайта, дальше не составит опять заглянуть в базу и найти, куда направить этот запрос уже по верх ipv4.

Если вам еще не надоело все это читать, то в итоге мы получим следующую картину: