Как Вы знаете, лучшее лечение – это профилактика. Наверное, очень многие, если не все, владельцы серверов сталкивались с ситуациями, когда сервер недоступен по причине избыточной нагрузки. А ведь такой ситуации могли и не быть, если бы администратор сервера своевременно узнал о проблеме. У многих владельцев виртуальных (VPS) или физических (dedicated) серверов возникает вполне резонный вопрос: «Как следить за нагрузкой на сервере?». Мы постараемся в нескольких статьях описать наиболее популярные способы и приемы, дадим практические советы по организации мониторинга сервера.

В данной статье мы опишем наиболее распространенные способы выявить причину нагрузки в режиме реального времени с помощью подручных средств и небольших консольных утилит. Сразу стоит отметить, что все операции нами будут выполняться с помощью командной строки сервера. Владельцы Linux и MacOS могут использовать для этого стандартные терминалы. Владельцам Windows мы бы рекомендовали использовать утилиту Putty. Подробная иструкция по использованию Putty Вы так же можете найти на нашем блоге: Работа с Putty. И так, предположим, что мы подключились к серверу с правами суперадминистратора (root). Что же делать дальше:

Мониторинг нагрузки на процессор, диски и использования оперативной памяти

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

Давайте подробно рассмотрим всю информацию, которую предоставляет нам top. И так, вверху мы видим текущее время на сервере, uptime (время работы) операционной системы без выключений и перезагрузок, количество пользователей, которые авторизованы на сервере, и среднюю нагрузку на сервере в данный момент, за последние 5 и 15 минут.
Следующая строка нам сообщает количество процессов и их состояние. Tasks – это суммарное количество запущенных процессов в системе. running – это количество выполняющихся в данный момент процессов, sleeping – количество «спящих процессов» (процессы находятся в состоянии ожидания или готовности), zombie – количество «зомби» процессов (это процессы, которые уже завершились, но их идентификатор все еще отображается в списке процессов).

Далее мы видим использование ресурсов процессора. us% – это процент времени, потраченного на выполнение процессов пользователей, для которых не задан приоритет. sy% – это процент времени, потраченного на выполнение процессов ядра. ni% – процент времени, потраченного на выполнение процессов с заданных приоритетом. wa% – это процент времени, потраченного на выполнение операций I\O (ввода\вывода), то есть дисковых операций. hi% – это процент времени, потраченный на обработку аппаратных прерываний. si% – процент времени, потраченного на обработку программных прерываний. st% – процент времени, «украденного» у виртуальной машины гипервизором для каких-либо других задач, к примеру, запуска другой виртуальной машины.

Далее размещается информация о использовании оперативной памяти. total – это суммарный объем оперативной памяти сервера, used – это объем использованной памяти, free – объем свободной памяти, buffers – объем буфера, cached – объем кеша операций ввода\вывода. Swap – аналогия файла подкачки в Windows. Если на сервере заканчивается свободная оперативная память, вместо нее начинает использоваться специальная область на жестком диске, swap-раздел. Аналогично с оперативной памятью, total – суммарный объем swap,used – объе использованного swap.

Здесь стоит отметить одну особенность Linux. Операционная система считает, что память, использованная под кеш дисковых операций, занята. На самом деле это не совсем так. При стандартных настройках ядра, если системе не хватает оперативной памяти для выполнения процессов, демон pdflush начинает сбрасывать кеш на жесткий диск, освобождая таким образом оперативную память для других приложений. Процент свободной оперативной памяти, при котором начинается сброс кеша на диск, задается параметром ядра vm.dirty_background_ratio и по умолчанию имеет значение 10.

Ниже мы видим список процессов и информацию о самих процессах. PID – это числовой идентификатор процесса, USER – это пользователь, который инициировал запуск процесса, PR – динамический приоритет процесса, NI – статический приоритет процесса, VIRT – объем использования виртуальной памяти (включая весь код, библиотеки и т.д.), RES – объем использования реальной оперативной памяти, SHR – объем использованной shared-памяти (эта память может использоваться и другими приложениями), S – статус процесса (выполняется, ожидает, остановлен и т.д.), %CPU – процент использования процессорного времени, %MEM – процент использования реальной оперативной памяти, TIME – время работы процесса с момента запуска, COMMAND – имя процесса.

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

man top

Успешной работы!

Продолжение следует…

Довольно часто наши клиенты задаются вопросом: «Какую же операционную систему выбрать для нового сервера?». В сети достаточно много холиваров на эту тему, мы же постараемся оперировать только фактами и статистикой из нашей работы. И так, для виртуальных выделенных серверов (VPS\VDS) в данный момент мы предлагаем следующие операционные системы:

Панель ISPmanager. Хоть разработчики панели ISPmanager и рекомендуют использовать последние версии CentOS, Debian или FreeBSD, корректная поддержка CentOS 6 и Debian 6, на момент написания данной статьи, не была реализована. Поддержка Ubuntu не планируется вообще.

Учитывая все вышеприведенные факты, на сегодняшний день мы бы рекомендовали остановить свой выбор на CentOS 5.7 или Debian 5.0.9. Надеемся, данная статья поможет Вам сделать правильный выбор. Успехов в работе с услугами HOSTLIFE!

Как Вы знаете, с 30 октября Украина вновь перешла на зимнее время, в то время как Россия отказалась от подобных изменений. В связи с этим на некоторых серверах не совсем точно отображается время, хотя часовые поясы заданы корректно. Для устранения данной проблемы, обычно, достаточно обновить на сервере базу знаний о часовых поясах, tzdata.

Для операционной системы CentOS достаточно выполнить команду

yum update tzdata

Для операционных систем Debian и Ubuntu нужно выполнить команды

apt-get update
apt-get upgrade tzdata

Чтобы задать часовой пояс, выполните команду

ln -s /usr/share/zoneinfo/Europe/Moscow /etc/localtime

или

ln -s /usr/share/zoneinfo/Europe/Kiev /etc/localtime

Так же, возможно, потребуется перезапуск некоторых служб, которые используют системное время (MySQL, Cron, syslog и т.д.). Если у Вас возникнут какие-либо трудности или вопросы, Вы можете обратиться за помощью к нашим операторам службы поддержки в любое удобное для Вас время.

Успешной работы!

Как Вы знаете, основной нашей задачей является предоставление качественных услуг хостинга. Качество хостинг-услуг определяется тремя основными критериями:

– круглосуточная и квалифицированная поддержка клиентов;
– стабильность основных интернет-каналов;
– стабильность работы серверного оборудования;

Центр поддержки клиентов HOSTLIFE работает в режиме  24\7, мы сотрудничаем  с крупнейшими в регионе магистральными провайдерами, поэтому по первым двум пунктам вопросов не возникает, и рассказывать особо нечего – все уже изложено на нашем сайте, и подтверждено  нашими клиентами на многочисленных страницах отзывов о хостинг-провайдерах в сети.  В данной статье мы бы хотели рассказать о том, как мы отслеживаем состояние нашего серверного оборудования.

Как было раньше

Известный факт, лучшее лечение – это профилактика. Большинство системных администраторов, по крайней мере те, кому не безразлична стабильность работы серверов, предпочитают иметь полную информацию о том, что же происходит на серверах  и какие проблемы возникают. Конечно же, можно периодически подключаться к серверам по SSH, RDP, VNC, etc, и проверять работу серверов, но, это весьма затратно по времени, и не совсем оправдано, ведь для подобных задач существует множество специализированных скриптов и даже комплексных систем мониторинга. В самом начале пути нашей компании мы использовали на серверах скрипты собственной разработки, которые автоматически отслеживали нагрузку на сервере, проверяли состояние основных сервисов, и при возникновении проблем, отправляли на e-mail нашим администраторам соответствующие уведомления. Такая схема имеет как свои плюсы, так и серьезные недостатки. Основным преимуществом этого  подхода являлось то, что при выполнении подобных скриптов практически не использовались ресурсы сервера. В то же время, если на сервере резко возрастала нагрузка, и скрипт при этом не успевал уведомить администраторов о проблеме, письмо с уведомлением оставалось в очереди сервера и отправлялось только тогда, когда нагрузка на сервер уменьшалась и имелось достаточно ресурсов для отправки данного уведомления – т.е. являлось уже бесполезным. К тому же, не сохранялась история и статистика, которая бы позволяла более детально разобраться в причинах возникающих проблем.

Разумеется , нужны были резервные способы уведомлений о проблемах на сервере. В качестве такого инструмента был выбран всем известный сервис http://host-tracker.com/, одним из хостинг-партнеров которого мы и являемся до сих пор -  узел  проверки доступности HostTracker  из Донецка  размещен на нашем оборудовании).  Данный сервис, несмотря на свои преимущества, конечно же не может сообщить о нагрузке на сервере или остановке какого-либо сервиса, но, очень оперативно и довольно точно сообщает о недоступности сервера из различных точек мира.

Время идет…

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

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

- мониторинг производительности и доступности серверов различных платформ, ИБП, свитчей и многих других устройств;
- распределенная система, возможность создания нескольких независимых точек мониторинга (масштабируемость);
- визуализация отчетов, построение графиков, карт, диаграмм;
- различные способы уведомлений (e-mail, jabber, sms);
- выполнение удаленных команд (автоматический перезапуск сервисов при падениях);
- автообнаружение узлов сети;
- WEB-мониторинг узла сети (нечто схожее с http://host-tracker.com/);
- эскалация уведомлений;
- поддержка SNMP 1-3, IPMI, SSH, TELNET;

Как это работает?

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

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

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

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

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

1)  Онлайн-мессенджеры  (ICQ, Skype, Web-чат) – для общих вопросов.

Обращаясь в онлайн-мессенджер, Вы как правило рассчитываете получить моментальный ответ на заданный вопрос, без выяснения каких-либо подробностей. Действительно, мессенджеры тем и хороши – общение происходит непосредственно в реальном времени. Это идеальный способ получить ответ на вопрос из категории общих вопросов, не требующих предоставления точной информации  о собственном аккаунте. Примеры таких вопросов:

- Какая версия ОС и программного обеспечения используется на хостинг-серверах для тарифов группы Standard и VIP?

- Каковы ограничения на расход ресурсов для отдельного хостинг-аккаунта?

- Можно ли разместить на начальном тарифе хостинга интернет-магазин/блог/галерею?

В 80% случаев эти вопросы основаны на тех, что уже изложены в разделе «Вопросы и Ответы», однако всегда можно обсудить интересующие ньюансы.

Не стоит использовать менеджер для обращений следующего характера:

- Сервер  хостинга X.X.X.X упал!

Каждый уважающий себя хостинг-провайдер имеет в распоряжении систему постоянного мониторинга доступности собственных серверов (и персональных серверов клиентов, находящихся на администровании).  В нашем случае система мониторинга имеет вообще три уровня – мониторинг служб на самом сервере, собственная внешняя система мониторинга и сбора статистики, работа со сторонним  сервисом распределенного мониторинга доступности из десятков точек Мира.  Проблемы периодически возникают у любого провайдера (не секрет, что в основном – по вине отдельных пользователей, пытающихся использовать услугу не по назначению), и провайдер узнает об этих проблемах за счет систем мониторинга моментально – раньше чем любой, даже самый бдительный клиент, поэтому такие сообщения будут иметь не информативный, а  отвлекающий характер. Лучшее решение в таких ситуациях -  подождать до получаса, и если проблема не решилась – уточнить сроки ее решения. 90% проблем, возникающих на серверах общего пользования (Shared-хостинг, VPS и т.д.) – решаются в течении нескольких минут.

- Мой личный сервер Y.Y.Y.Y недоступен!

- На моем сайте возникла ошибка!

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

Зачем же отнимать время у себя и у провайдера? Лучше сразу открыть тикет и получить решение проблемы в кратчайшие возможные сроки.

2) Телефон – это аналог онлайн-мессенджера, не более.

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

Речь не идет о телефонах отдела продаж и руководства  компании, – данные номера не относятся к службе поддержки.

3) Тикет-система – средство решения проблем, а не получения консультаций.

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

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

4) Вы работаете с компанией, а не с отдельными людьми.

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

5) Знание Договора – не формальность, а необходимость.

При регистрации на сайте клиенту всегда предлагается ознакомиться с договором-офертой – виртуальным документом, имеющим реальную  юридическую силу и регламентирующим сотрудничество как для провайдера, так и для клиента. Тем не менее, по статистике большая часть клиентов обращается  к ознакомлению с Договором лишь при возникновении спорных моментов, например таких как возврат средств, возможность размещения проекта, который не рассчитан на данную услугу, и т.д. В результате – даже если клиент был не прав изначально, все равно остается негатив, который проецируется на провайдера – не предупредили заранее, не уточнили со своей стороны, и прочее, прочее, прочее.  Это выливается в ненужные споры и потраченное время для обеих сторон.

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

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

Надеемся, что данная статья будет полезной как для существующих клиентов HOSTLIFE, так и для тех, кто хочет присоединиться к их числу.

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

Допустим, Вы несколько месяцев или даже лет работаете только с виртуальным хостингом, и даже не задумываетесь о таких вопросах, как администрирование сервера, оптимизация его работы, мониторинг доступности веб-сайтов, не углубляетесь в вопросы различных тонкостей настройки системных сервисов и ОС. Это нормально, и даже оправдано – ведь администрированием сервера хостинга занимается хостинг-провайдер, а не клиент! Тем не менее, в  момент принятия решения о переходе на собственный сервер, даже виртуальный,именно  это может стать причиной отказа от дальнейшего развития проекта. Вас может остановить необходимость либо самостоятельно углубляться в «дебри администрирования», либо же дополнительно оплачивать услуги специалистов, т.к. базового администрирования, предоставляемого провайдером, может быть недостаточно.

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

Когда проекту становится тесно на обычном хостинге, достаточно часто первый вопрос, который задает клиент, звучит так – «Могу ли я платить больше и остаться на своем хостинге?». Разумеется,  такое простое «решение» проблемы невозможно, т.к. ни один провайдер не будет ставить на одну чашу весов стабильность работы большинства пользователей сервера и размещение отдельного проблемного проекта. Тем не менее, мы учли ключевое желание большинства пользователей – остаться на виртуальном хостинге и получить больше ресурсов в свое распоряжение.

Это желание и воплотилось в качественно новую услугу хостинга веб-сайтов – VIP-хостинг . В чем разница между обычным хостингом и VIP?

Типовая конфигурация хостинг-сервера, используемого нами в качестве основы для хостинга тарифной группы Standard:

Процессор: Intel(R) Core(TM) i5 CPU 750 @ 2.67GHz
Объем ОЗУ: 8 GB
Дисковая подсистема: 3x 1TB HDD SATA II
Количество пользователей со средним числом сайтов в 5-10 шт.: 120-150.

Типовая конфигурация хостинг-сервера, используемого для VIP-хостинга:

Процессор: Intel(R) Xeon(R) CPU X5660 @ 2.80GHz
Объем ОЗУ: 12 GB
Дисковая подсистема: 3x 1TB HDD SATA II Enterprise
Количество пользователей со средним числом сайтов в 1-4 шт.: 20-30 (не более 30).

На сервере тарифной группы VIP размещается не более 30 клиентских аккаунтов, что обеспечивает возможность выделения каждому клиенту значительно большего объема ресурсов, чем на стандартных тарифных планах. Данное решение уже пришлось  по душе клиентам, чьи сайты создают высокие нагрузки на оборудование, но они хотели бы продолжить работу на виртуальном хостинге. На сегодняшний день данная услуга доступна на площадке в Германии. Запланирован ее запуск и в Украине, но немного позже.

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

Желаем успешного развития Ваших проектов в сотрудничестве с HOSTLIFE!

Недавно была обнаружена уязвимость в Apache всех версий, использование которой, при определенных условиях, могло привести к отказу в обслуживании. Проблема заключается в следующем: при выполнении некоторого perl-скрипта веб-серверу в несколько потоков отправляются простые запросы вида:

HEAD / HTTP/1.1
Host: www.example.com
Range: bytes=0-,5-0,5-1,5-2,5-3,5-4,<...>,5-1299,5-1300
Accept-Encoding: gzip
Connection: close

В результате чего, Apache пытается сгенерировать ответ, подсчитатывая в памяти Content-Length (размер тела запрашиваемого объекта) перекрывающихся частей запрашиваемого файла. Данный ответ может использовать значительную часть оперативной памяти сервера. Соответственно, в такой ситуации, потребление памяти со стороны Apache достаточно быстро растет, что даже при небольшом количестве запросов может привести к серьезным проблемам.

Как проверить, уязвим ли Ваш сервер?

Достаточно отправить серверу два простых запроса к любому статическому файлу, к примеру, robots.txt:

Как устранить уязвимость?

Если на Вашем сервере установлен Nginx, достаточно в конфигурационный файл nginx добавить следующие параметры:

apachectl -M

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

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

Заблуждение №1. На хостинге можно разместить любые скрипты, если хостинг соответствует их системным требованиям.

Пожалуй, наиболее частое заблуждение клиентов, которое  построено на том, что во внимание не принимается на главная  особенность shared-хостинга – отсутствие для пользователя  гарантировано выделенных системных ресурсов.  Виртуальный хостинг представляет собой аренду ячейки на сервере, на  котором работает большое число пользователей. Проще говоря,  запросы ко всем расположенным на сервере хостинга сайтам обрабатываются одним и тем же веб-сервером Apache, все скрипты обрабатываются одним интерпретатором PHP, и все базы данных обслуживаются одним сервером баз данных MySQL.  Системные ресурсы на таком сервере распределяются динамически – в худшем случае основную их долю  потребляют  наиболее нагруженные проекты, а остальные проекты довольствуются тем что остается. Во избежание подобных ситуаций,  администратором сервера обеспечивается контроль равномерного распределения ресурсов, – для этой цели и вводятся некоторые ограничения на работу с услугой, включающие в себя и ограничение на используемые скрипты. Если скрипты, которые клиент желает разместить (к примеру торрент-трекер, чат или мини-поисковая система), требуют значительных вычислительных мощностей, то их размещение на хостинге станет причиной нарушения нормального распределения ресурсов и вызовет проблемы в работе большинства пользователей (вплоть до нарушения стабильной работы сервера). Для корректной работы подобных проектов требуются гарантировано выделенные системные ресурсы – VPS/VDS или выделенный сервер, но это тема уже другой статьи.

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

Заблуждение №2. Для безлимитного хостинга  нет  рамок расхода ресурсов.

Концепция безлимитного хостинга -  это больше, чем  банальная отмена лимитов на дисковую квоту и расход трафика. Безлимитный хостинг сегодня – это комплексная услуга «всё в одном», позволяющая клиенту успешно развивать собственные  проекты без оглядки на ограничения по ресурсам. Однако нельзя забывать о том, что ресурсы сервера – это величина конечная, и реализовать полное отсутствие лимитов невозможно технически, но можно убрать жесткие рамки, оставив лишь  максимально допустимые пределы нагрузки на сервер для отдельного пользователя.  Такой хостинг можно назвать безлимитным, и при такой концепции для 90% пользователей услуги безлимит будет являться таковым  в прямом смысле этого слова, так как достигнуть планки максимально допустимой нагрузки очень затруднительно. В оставшиеся 10% входят пользователи, которые хотят воспользоваться услугой хостинга не по назначению, веря в заблуждение о безграничности ресурсов и располагая на хостинге заведомо не соответствующие данной услуге проекты, такие как файловые обменники, файловые хранилиша, системы распределения трафика, и так далее.

Перед размещением на виртуальном хостинге проекта, требующего заведомо большого объема ресурсов – дискового пространства, трафика, или же вычислительной мощности, необходимо получить консультацию у операторов службы поддержки.

Заблуждение №3. Настройки сервера хостинга можно менять любым образом.

Виртуальный хостинг на данный момент обладает известной гибкостью в настройке.  К примеру, пользователям  нашего хостинга доступны возможности настройки веб-сервера Apache с помощью файла .htaccess, а также  гибкая настройка интерпретатора PHP с помощью пользовательского файла php.ini.  Настройки хостинга являются оптимальными для работы большинства распространенных скриптов и систем управления контентом, но тем не менее, периодически мы получаем сообщения от пользователей о необходимости установки какой-либо библиотеки или компонента, или изменения глобальных настроек сервера в соответствии с системными требованиями некоторых скриптов. На подобные просьбы в большинстве случаев мы вынуждены отвечать отказом, и причина проста – хостинг является публичной услугой, а не индивидуальной. Та настройка, которая хороша для отдельно взятого пользователя, не будет оптимальной для большинства, а в ряде случаев изменение настроек станет причиной проблем в работе уже размещенных на хостинге сайтов.

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

Заблуждение №4. Избыточная нагрузка на хостинге со стороны одного пользователя  не возможна.

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

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

Заблуждение №5. Нагрузка на хостинг зависит только от посещаемости сайтов.

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

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

Заблуждение №6. Регулярный backup на хостинге делается для клиента.

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

Очень часто клиенты обращаются с просьбой восстановить аккаунт из имеющейся на сервере резервной копии для отмены каких-либо некорректных изменений на сайте,  и мы всегда охотно идем навстречу. Однако, иногда запрос на восстановление данных оказывается запоздалым – на момент создания резервной копии проблема уже имела место, а более ранние копии отсутствуют. В подобных ситуациях клиенты часто винят хостинг-провайдера, поддаваясь заблуждению и считая, что резервные копии на сервере делаются для того, чтобы  клиент имел возможность всегда  отменить любые некорректные действия. На самом деле резервные копии создаются провайдером для страховки сохранения данных пользователей  в непредвиденных ситуациях, например при сбое оборудования. Ежедневное резервное копирование – это страховка, которая позволяет восстановить данные даже тогда, когда основной носитель выходит из строя безвозвратно, а возможность восстановления данных пользователей по запросу – это всего лишь приятное дополнение, но не цель резервирования. Современные панели управления, в частности DirectAdmin и сPanel, используемые на хостинге от HOSTLIFE, позволяют пользователям при необходимости самостоятельно создавать независимые резервные копии. Данной возможностью желательно не пренебрегать, и всегда пользоваться перед тем, как вносить какие-либо серьезные изменения, – тогда надобность  в восстановлении данных из автоматически создаваемых резервных копий отпадет.

Заблуждение №7. Выбирать хостинг нужно по цене.

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

Чтобы не попасть в просак, при выборе хостинга нужно определиться  в первую очередь с тем, что Вы хотите получить, и уже потом думать о стоимости. Нужно четко определить для себя рамки – в размещении сайтов на одном аккаунте, в количестве отправляемых писем в сутки,  в расходе трафика и необходимом дисковом пространстве (хотя бы примерные рамки), в использовании планировщика Cron, и т.д. Если проект является достаточно нагруженным – нужно смотреть  в сторону VIP-хостинга, где число аккаунтов пользователей, размещаемых на сервере, в разы меньше, нежели на стандартном хостинге (к примеру, 30 аккаунтов против 100-150), а конфигурация сервера более производительна. Если размещаемые проекты – это легкие сайты, например сайты-визитки или домашние странички – возможности «топовых» тарифных планов просто не будут использоваться, достаточно будет стандартных предложений.  Уважающий себя хостинг-провайдер не будет уделять стабильности работы серверов с «дорогими» тарифными планами больше внимания, нежели серверам с «дешевыми»  предложениями, – стабильность всегда должна быть на неизменно высоком уровне. Именно такого подхода  мы и придерживаемся.

Заблуждение №8. Автоматический тестовый период – гарантия качества хостинга.

Золотая пословица «доверяй, но проверяй» не потеряла своей актуальности и для  it-услуг. Желание клиентов  протестировать работу с хостингом перед покупкой услуги вполне понятно и более чем оправданно, поэтому практически любой провайдер предложит Вам  бесплатный тестовый период, как минимум на несколько дней (обычный срок – неделя). У многих провайдеров система  активации тестового периода работает автоматически – достаточно указать соответствующую галочку при при формировании заказа. Мы же пошли другим путем – тестовый период на услуги хостинга от  HOSTLIFE предоставляется только после регистрации клиента, по официальному запросу в службу технической поддержки,после выяснения подробностей касательно  характера размещаемых проектов. Кому-то покажется, что такой подход не столь удобен, как автоматическая активация, – возможно. Но зато тестовый период получают только проверенные пользователи, которые будут использовать услугу по назначению.  Такой подход сохраняет стабильность хостинга – ведь возможность бесплатной работы с услугой, пусть даже и ограниченное время, как магнит привлекает различных не чистых на руку людей, которые будут использовать хостинг во вредоносных целях, и желали бы делать это не только бесплатно, но и анонимно. Таких возможностей мы не дадим, как не даст ни один хостинг-провайдер, который предоставляет действительно качественный сервис, или по меньшей мере стремиться к этому.

Заблуждение №9. Возврат средств должен распространяться на весь период действия хостинга.

Качество всегда имеет свою цену – это общеизвестный факт. Однако, иногда выбранная услуга может по каким-либо причинам не подойти пользователю, а узнать об этом он может только после работы с ней, иногда по истечению длительного срока. Для  решения подобных ситуаций у многих хостинг-провайдеров предусмотрен возврат средств. Здесь есть несколько вариантов – кто-то может предложить Вам полный возврат средств в течении всего оплаченного срока,  большинство же  хостинг-провайдеров предложит лимитированные условия возврата средств. Например, клиенты HOSTLIFE могут вернуть средства, оплаченные наперед, за полные месяцы услуги, в течении первых 30 дней работы, в том случае, если заказ на данный вид  услуг является первым. Если речь идет о виртуальном хостинге – то возврат возможен в том случае, если виртуальный хостинг заказывается впервые. Иногда у пользователей возникает вопрос, почему мы выбрали именно такую политику, и в чем заключается сложность при возврате средств, к примеру, спустя полгода работы с услугой. Ответ прост – никаких сложностей нет, но возврат средств должен защищать права тех пользователей, кому услуга действительно не подошла , а не пользователей, желающих  отказаться от обязательств, взятых на себя ранее, без объективных на то причин. Любое сотрудничество предусматривает определенные  обязательства со стороны обеих сторон, которые подкрепляются какими-либо гарантиями. Оплата сразу на длительный срок – это подтверждение решения о долговременном сотрудничестве со стороны клиента. Возможность возврата средств в любое время – это возможность для клиента  в любой момент отказаться от сотрудничества, но отсутствие обязательств со стороны клиента неизбежно приводит и к отсутствию (уменьшению их) со стороны провайдера.  В 90% случаев такое сотрудничество уже не может быть долговременным, а следовательно, и успешным. Возвращать средства в течении всего срока действия заказа может только провайдер-однодневка, живущий одним днем и не думающий о перспективах развития.

В работе с HOSTLIFE успешное сотрудничество – это сотрудничество, в котором заинтересованы на длительный срок обе стороны.  Это хорошо понимаем мы, и знает каждый клиент, работающий  с нами длительный срок, и наблюдающий за успешным ростом собственных проектов на нашем хостинге.

Заблуждение №10. На хорошем хостинге не бывает проблем.

Стопроцентный аптайм работы хостинга – это миф, который является желанным для всех пользователей хостинга,  и одновременно с этим – это эталон, к котором стремимся мы, как наверное, и любой другой хостинг-провайдер. У нас для этого есть все, что нужно – надежная техническая база, и команда профессионалов,  на 100% преданных своему делу. Но кроме этого,есть и  обстоятельства, которые от нас не зависят и предусмотреть которые  невозможно. Такие проблемы иногда встают на пути любого хостинг-провайдера, и возникают как правило  по вине пользователей хостинга, ведь shared-хостинг – это услуга, не предусматривающая для пользователей гарантировано выделенных ресурсов.  Соответственно, стабильность работы на виртуальном хостинге в первую очередь зависит от самих пользователей услуги.  Иногда у отдельных пользователей возникают проблемы, которые не могут не повлиять на стабильность работы сервера в целом, – это могут быть ддос-атаки, намеренное или случайное превышение максимально допустимых рамок расхода ресурсов, размещение проектов, заведомо не соответствующих услуге, или же размещение скриптов, которые могут создавать проблему неявно, и т.д. Разумеется, благодаря круглосуточному мониторингу стабильности серверов мы узнаем о проблемах моментально, и всегда решаем их в максимально короткие сроки, но такие проблемы неизбежны. Аккаунты на серверах хостинга открываются в автоматическом режиме, и хотя они периодически проверяются, предусмотреть всё нельзя, однако реально решать проблемы сразу при их возникновении, не теряя ни минуты. Такой подход мы можем гарантировать, и следуем ему на протяжении многолетней истории компании, благодаря чему каждый наш клиент твердо знает, что стабильность наших услуг находится на максимально возможном уровне.

* * *

Подводя итоги, хотим сказать, что shared-хостинг, несмотря на все свое многообразие  – это сформировавшийся тип  услуг для размещения веб-сайтов в сети Интернет, являющийся в большинстве случаев стартовой точкой развития проектов.   Как и любой другой тип услуг, например VPS или выделенный сервер, виртуальный хостинг имеет и очевидные преимущества, и заметные недостатки, на которые стоит обратить внимание, определяясь с выбором услуги. Только четкая картина собственных потребностей, плюс анализ  независимых отзывов и мнений  о провайдере позволит сделать правильный выбор, чего мы Вам искренне желаем.

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

Проясним, что же из себя представляем система виртуализации и для чего она предназначена. Виртуализация, по своей сути,  это средство для создания виртуальных серверов (контейнеров) внутри физического сервера. В общем смысле данного термина, ресурсы могут быть распределены географически, иметь различные аппаратные модули, работать на различных платформах, но объединяться для решения общей задачи в рамках одной виртуальной среды. Но, мы поговорим несколько об ином способе выделения виртуальных ресурсах. Речь пойдет о виртуальных выделенных серверах (Virtual Private (Dedicated) Servers, VPS/VDS).

В рамках данной услуги клиенту выделяется часть физических ресурсов сервера (вычислительные мощности и модуль хранения данных), которые используются только одним клиентом и не зависят от работы остальных виртуальных контейнеров (VPS) на одном физическом сервере. Тоесть, создается виртуальный сервер внутри физического сервера, который имеет органиченный объем физических ресурсов, но, при этом, работает как полноценный сервер. Основное различие систем виртуализации заключается в том, как виртуальные серверы получают ресурсы и работают с аппаратной частью сервера. Существует три основных способа виртуализации:

1. Аппаратная виртуализация – разделение ресурсов сервера на аппаратном уровне (KVM, Xen).
2. Паравиртуализация – сопосб, при котором операционная система клиента несколько модифицируется для работы в виртуальной серде. Вместо прямого обращения к аппаратной части, операционная система обращается к программному обеспечению гипервизора. Основным недостатком такого способа является необходимость модификации ядра операционной системы, что возможно только в Open Source проектах или в том случае, если система виртуализации разработана с учетом возможностей отдельно взятой операционной системы (Xen).
3. Виртуализация на уровне операционной системы – возможность создавать независимые виртуальные среды внутри операционной системы. Каждый виртуальный сервер может иметь свою операционную систему, но должно использоваться такое же ядро, как и у основной ОС. Другими словами, если на гипервизоре используется операционная система семейства Linux, то операционные системы Windows иди FreeBSD установить на виртуальный сервер уже не получится. При таком подходе распределением ресурсов между виртуальными серверами занимается основная операционная система, без участия программной прослойки в виде гипервизора (OpenVZ, Virtuozzo).

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

Виртуализация на базе технологии Xen

Xen – кросс-платформенная разработка компьютерной лаборатории Кембриджского университета, которая распространяется по лицензии GPL (бесплатно). Поддерживается как аппаратная, так и паравиртуализация. При использовании паравиртуализации (далее PV) модифицируется ядро основной операционной системы для работы с Xen. Клиентская операционная система не может выполнять привилегированные операции, вместо этого отправляется запрос гипервизору на выполнение того или иного действия. Основные измениня в клиентской операционной системе затрагивают только ядро, но могут изменяться и некотороые библиотеки.

В режиме аппаратной виртуализации «домен» (виртуальная машина) не знает о существовании гипервизора. Эмулируется реальное программное обеспечение, после загрузки операционной системы подгружаются дополнительные PV-драйверы, предназначенные для ускорения выполения операций с виртуальными устройствами.

Виртуализация на базе проекта OpenVZ

OpneVZ – система виртуализации, основанная на ядре Linux и использующая виртуализацию на уровне операционной системы. Поскольку сама система OpenVZ базируется на Linux, то и клиент сможет испоользовать только дистрибутивы Linux (Fedora, RHEL, Centos, Debian, SuSE). Windows и *BSD дистрибутивы не могут быть использованы из-за значительных отличий ядра.

OpenVZ состоит непосредственно из модифицированного ядра Linux и комплекта пользовательских утилит. Каждая виртуальная машина на гипервизоре выглядит как полноценный сервер, имея свои независимые файлы, пользователей, сеть, дерево процессов, файрвол и т.д. Поддерживается создание копий файловой системы контейнера и миграция контейнера на другую ноду. По информации разработчиков, падение в производительности, в сравнении непосредственно с физическим сервером, составляет не более 1-3%, которые используются для работы самой виртуализации.

Проект OpenVZ разрабатывается сообществом, при поддержке компании Parallels, Inc. и распространяется по лицензии GPL 2 (бесплатно), за счет чего является одной из наиболее распростаненных систем виртуализации на рынке хостинг-услуг.

Виртуализация на базе Parallels Virtuozzo Containers

Parallels Virtuozzo Containers – весьма популярное и распростаненное решение от компании Parallels, Inc. Распределение ресурсов производится на уровне операционной системы. Существуют версии Parallels Virtuozzo Containers для работы в средах Linux (на основе OpenVZ) и Windows.

Parallels Virtuozzo Containers базируется на разработке OpenVZ, однако имеет ряд значительных улучшений, исправлений и доработок. Так, Parallels Virtuozzo Containers имеет несколько GUI-панелей, удобную систему контроля за конейнерами и нодами, множество локализаций интерфейсов, в том числе и русскую. Для клиента наиболее важной панелью является Virtuozzo Power Panel, которая предоставляет клиенту расширенные функциональные возможности, такие как:

• удаленная перезагрузка контейнера даже при отсутствии доступа к самому серверу любыми другими способами;
• переустановка операционной системы с возможностью сохранения прежних данных в отдельный каталог /old;
• резервное копирование контейнера (создание слепка);
• встроенный файловый менеджер;
• доступ к файрволу сервера;
• java-клиенты  ssh и rdp;
• статистика использования ресурсов сервера и трафика;
• управление процессами операционной системы;

Система виртуализации поддерживает установку большинства известных Linux-дистрибутивов и миграцию контейнеров на соседнюю ноду без простоя в работе сервера (без downtime). Поддерживаются важные модули ядра операционной системы, такие как iptables, tun/tap, quotas. Скорость работы виртуальной машины практически не отличается от скорости работы основного (физического) сервера. Легкость масштабирования и добавления к основной системе виртуализации новых нод предоставляет практически неограниченные возможности для роста и дальнейшего развития ресурса.

Эпилог

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

При работе с услугой VPS/VDS выбор технологии виртуализации является строительством фундамента для дальнейшего успешного развития проекта, не больше и не меньше. Мы надеемся, что данная статья поможет сделать Вам правильный выбор.

Желаем успешной работы с услугами HOSTLIFE!

Почему же вебмастер должен работать с партнерской программой хостинг-провайдера? Ответить на данный вопрос мы постараемся в этой статье, посвященной партнерской программе от HOSTLIFE.

От ежедневного  появления десятков новых многообещающих партерок уже рябит в глазах, и выбор партнерской программы для сотрудничества часто становится непростым. Действительно, как определить, кому можно доверять,а кому нет? Партнерская программа хостинг-провайдера в данном случае будет приятным исключением, поскольку является максимально прозрачной во всех отношениях. Мы работаем на рынке хостинга уже 6 лет, и знаем, как сделать этот рынок лучше. Партнерская программа – не исключение.

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

Напомним вкратце условия партнерской программы от HOSTLIFE:

Работая с нашей партнерской программой, Вы получаете:
- 15% от каждого заказа виртуального хостинга;
- 10% от каждого заказа виртуального сервера;
- 5% от каждого заказа выделенного сервера.

Доступ к партнерскому разделу, в котором Вы можете найти промо-материалы, партнерскую ссылку и управлять партнерским счетом, открывается автоматически, при регистрации на нашем сайте: www.hostlife.net.
Раздел будет доступен в меню Партнер в биллинг-панели.

Простой пример: По Вашей ссылке пришел клиент, который оплатил заказ на виртуальный хостинг по тарифному плану Deluxe на год ($407,9). Сумма Вашего партнерского вознаграждения в данном случае составит $61,1!

Есть два основных направления работы с партнерской программой:

1) Партнерская программа как средство минимизации расходов на услуги хостинга и источник дополнительного заработка в Интернет;

2)Партнерская программа как основной способ заработка в сети Интернет.

Рассмотрим подробно оба направления.

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

Реализация данного направления работы с партнерской программой может быть различной. Вы можете просто разместить наш рекламный банер или партнерскую ссылку  на собственных сайтах, в подписи на форуме или на своей  страничке в социальной сети, и зарабатывать деньги за счет заказов клиентов, которых Вы приведете по партнерской  ссылке. Данный подход, как и любой пассивный заработок, привлекает в первую очередь отсутствием необходимости в постоянной работе. Вам достаточно единожды запустить систему,  разместив промо-материалы HOSTLIFE на посещаемых ресурсах, и наслаждаться растущими цифрами на собственном партнерском счете!

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

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

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

Разумеется, представленными выше вариантами Ваши возможности в партерстве с HOSTLIFE  не ограничиваются. Мы всегда открыты для новых идей, и  рады успешному и  взаимовыгодному сотрудничеству!