Виртуальный (shared) хостинг для сайтов

Веб-студии

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

Интернет-магазины

поддерживают оптимальную производительность при резких скачках посещаемости в сезон, дни распродаж и в канун праздников.

Владельцы интернет-сервисов

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

Порталы и сайты-визитки

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

Разработчики ПО

используют услуги виртуального хостинга для проектирования, разработки и тестирования новых программных продуктов для web’а.

Остались вопросы?

Получить консультацию

Бизнес в сфере хостинга: как запустить shared-хостинг

Это вторая статья из цикла “Как организовать хостинг-бизнес”. В первой мы рассказали о перепродаже доменов и SSL-сертификатов. Второй материал описывает запуск виртуального хостинга: какое оборудование и программное обеспечение использовать, как его настраивать. Поможет запустить бизнес быстро и без больших затрат.

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

Что нужно для начала

Для начала разберемся с понятиями.

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

Виртуальный хостинг можно запустить без собственного оборудования. Для этого вам понадобится:

1. два сервера (виртуальных или выделенных),
2. программное обеспечение для размещения сайтов (панель управления хостингом и IP-адресами),
3. биллинговая платформа для обработки платежей
4. соглашение с платежной системой,
5. сайт для продажи услуг.

Два сервера нужны для большей стабильности виртуального хостинга: один для работы биллинговой платформы BILLmanager, второй для размещения сайтов клиентов. Оба сервера могут быть виртуальными, первый менее мощным, второй более мощным либо выделенным.

Рекомендуем использовать VDS с виртуализацией KVM, 2 Гб оперативной памяти, 50 Гб жесткого диска. Арендовать серверы можно у одного из партнеров ISPsystem.

Необходимое программное обеспечение

Для продажи виртуального хостинга на VDS необходимо установить четыре программы: ISPmanager Business, BILLmanager, IPmanager и DNSmanager.

ISPmanager Business создана специально для организации виртуального хостинга. Она позволяет управлять несколькими серверами из единого интерфейса, разграничивать ресурсы между пользователями, отслеживать статистику.

BILLmanager автоматизирует работу хостинга: регистрацию клиентов, заказ и обработку услуг, формирование счетов на оплату, договоров, актов выполненных работ. Биллинг может поддерживать несколько проектов и юридических лиц.

IPmanager предназначен для хранения информации о сетях и IP-адресах. Для создания shared-хостинга IP-адреса не нужны, но IPmanager необходим для интеграции ISPmanager и BILLmanager.

DNSmanager поможет настроить сервера имен и разместить на них домены клиентов. Базовые версии IPmanager и DNSmanager доступны без покупки лицензии. Использование BILLmanager бесплатно до 50 клиентов. Для установки ISPmanager Business необходимо купить лицензию.

Базовые версии IPmanager и DNSmanager доступны без покупки лицензии. Использование BILLmanager бесплатно до 50 клиентов. Для установки ISPmanager Business необходимо купить лицензию.

Установка программного обеспечения

На каждом сервере должна быть установлена CentOS 7 x64. Обратите внимание, что BILLmanager и ISPmanager Business должны быть установлены на разных серверах. IPmanager и DNSmanager установите на тот же сервер, что и BILLmanager.

Процесс установки программного обеспечения подробно описан в документации:

Настройка панелей и взаимодействия между ними

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

DNSmanager и IPmanager

DNSmanager и IPmanager установлены на одном сервере, поэтому порядок их настройки будет следующий:

ISPmanager

Перед настройкой ISPmanager определитесь с тарифами, которые хотите создать. Определите ограничение оперативной памяти, места на диске, мощность процессора, количество сайтов, трафика, баз данных и почтовых ящиков.

Порядок настройки:

Чтобы расширить возможности панели по разделению ресурсов между пользователями, а также улучшить стабильность, безопасность и производительность сервера, вы можете подключить модуль CloudLinux.Для этого после установки ISPmanager Business перейдите на my.ispsystem.com, закажите лицензию на модуль CloudLinux и произведите конвертацию сервера. Подробнее в документации: Модуль CloudLinux.

BILLmanager

BILLmanager — это программа для продажи услуг и приема платежей. Бесплатная версия позволяет создавать до 50 клиентов. Когда вы окрепнете и вырастите, то сможете перейти на платную версию. Бесплатная версии включает в себя все возможности BILLmanager. Позже обновиться до платной версии вы сможете в один клик прямо из панели. Процесс установки подробно описан в документации: Установка и обновление BILLmanager.После установки произведите первоначальную настройку: выберите язык интерфейса, заполните информацию о компании, добавьте свой логотип и пр. Далее настройте интеграцию BILLmanager с IPmanager и DNSmanager.Чтобы сразу после оплаты заказа в биллинге клиент получал услугу и доступ в панель управления web-сервером, необходимо подключить ISPmanager Business к BILLmanager. Также на этапе подключения ISPmanager вы можете создать тарифы. Подключение к ISPmanager.

Настройка BILLmanager

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

О каждом из этих пунктов мы писали в статье Бизнес в сфере хостинга: как быстро начать продавать домены и SSL-сертификаты.

Настройка продажи дополнительных услуг

Домены и SSL

В дополнение к виртуальному хостингу можно продавать домены, SSL-сертификаты и продукты ISPsystem. Чтобы не организовывать торговлю доменами и SSL с «нуля», настройте перепродажу от действующих продавцов. Подробнее в первой статье.

Лицензии на ПО ISPsystem

Кроме доменов и SSL вы можете перепродавать лицензии на программное обеспечение ISPsystem. Для всех клиентов действуют скидки от оборота: чем больше продаете, тем больше скидка. Реселлерам мы предоставляем партнер-кит. Хостинг-провайдеры и дата-центры могут подключиться к Партнерской программе. Чтобы начать реселлинг панелей ISPsystem при создании обработчика услуг выбирайте “Лицензии ISPsystem”.Подробнее в документации: Настройка перепродажи лицензий ISPsystem

Проверка работы программного обеспечения

Создайте в BILLmanager пользователя, войдите в его аккаунт и попробуйте заказать хостинг или домен. Проверьте работу всех услуг. Если возникнут вопросы, обратитесь к документации или напишите в отдел по работе с клиентами ISPsystem.

Начните продавать

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

После налаживания бизнеса по продаже shared-хостинга вы можете организовать хостинг VDS.

Лучший shared хостинг для сайта

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

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

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

Эти хостинги являются одними из лучших в соотношении цена и качество предоставляемых услуг.

Лучшие западные хостинги для сайта:

Как правильно выбрать веб-хостинг?

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

• Скорость: насколько отзывчивым должен быть сайт? Не имеет значения какого характера сайт будут посещать пользователи. Корпоративный сайт большой компании или просто лендинг должны загружаться одинаково быстро. Ведь никто не станет ждать загрузки Вашего сайта более нескольких секунд и уйдёт искать то что нужно к Вашему конкуренту.
• Полоса пропускания: отражает показатель передаваемых данных за месяц. Это требование к хостингу показывает сколько посетителей Вы ожидаете принять на своём сайте за месяц. Если по мере роста популярности сайт, он начнёт «просидать» по скорости отклика, то об этом следует подумать заранее. Кроме того, нужно заранее подумать о том, какого рода на сайте ожидается контент: текстовые блоки, изображения, видеофайлы, музыка. Графические элементы требуют гораздо большей полосы пропускания, чем просто текст.
• Место хранения: сколько страниц и данных на Вашем сайте? Вы должны заранее прикинуть общий объём данных, из которых состоит Ваш сайт, чтобы минимизировать риски нехватки дискового пространства в будущем. Подумайте, возможно стоит использовать услуги хостинга изображений или видеофайлов, если ресурсы такого рода Ваш основной контент.
• Техническая поддержка: требуется ли Вашему сайту помощь в настройке хостинга? Если это Ваш первый сайт, у Вас наверняка могут возникнуть некоторые сложности с первоначальной настройкой сайта. Также в случаях, когда сайт начнёт давать сбои, техническая поддержка сможет в очень короткие сроки если не решить проблему целиком, то определить источник проблемы. Таким образом это поможет предотвратить длительные простои сайта.

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

 

InMotion Hosting

InMotion hosting предлагает отличные тарифные планы по недорогой стоимости для всех видов хостинга.

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

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

Стартовая стоимость на обычном Shared-хостинге начинается от 3,99 долл./месяц на момент написания статьи. Он предлагает разместить один или два сайта на неограниченном дисковом пространстве. Пропускная способность и количество Email ящиков тоже не ограниченно. Кроме того предоставляется бесплатный SSL.

Для большей производительности можно рассмотреть следующий по производительности тарифный план Power за 5,99 долл./месяц, который позволяет разместить уже до 6 сайтов на одной учетке и до 100 поддоменов. Тарифный План Pro стоимостью 13,99 долл./месяц предлагает все что нужно для крупных интернет-проектов: все опции предыдущих тарифов плюс неограниченное количество баз данных MySQL и неограниченное количество сайтов на одном сервере.

 

Bluehost

Хотите получить надежный веб-хостинг по наименьшей стоимости? Тогда стартовый тарифный план

Basic от Bluehost — Ваш выбор. Он предлагает 50 Гбайт памяти для сайта, 5 учетных записей электронной почты с максимальным объемом хранения 100 МБ каждый и до 25 поддоменов. Стоимость такого удовольствия составляет 2,95 долл./месяц.

Следующий план Plus предусматривает неограниченное число сайтов, неограниченное хранилище, неограниченные учетные записи электронной почты и неограниченное количество поддоменов. Стоимость составляет 5,45 долл./месяц.

Как и большинство веб-хостингов, Bluehost предлагает cPanel для управления Вашими сайтами.

 

Media Temple

Media Temple обещает супер стабильное качество услуг за свои деньги. Стабильность и быстродействие — главные критерии выбор этого хостинга для сайта. Конечно, стоимость тарифных планов намного дороже выше рассмотренных конкурентов. Но под если Вам нужна гарантированная работа сайта в режиме 24/7, то лучше хостинга просто не найти.

Стоимость тарифных планов представлена ниже:

 

Стоимость на самом дешевом тарифе начинается с 20 долл./месяц. За эти деньги Вы получаете 20 Гбайт места на SSD-накопителе, 1 Тбайт полосу пропускания, до 100 веб-сайтов.

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

 

SiteGround

SiteGround — хороший вариант, если у Вас не много опыта в выборе «правильного» хостинга. Начните с плана StartUp

по цене 3,95 долл./месяц, который предлагает 10 Гбайт места под файлы и достаточную пропускную способность для приёма до 10 000 посетителей в месяц. Кроме того, Вы получаете бесплатное доменное имя, неограниченное количество электронных писем, доступ к cPanel и SSH и даже поддержку CloudFlare.

Если Вы планируете иметь трафик с посещениями до 25 000 пользователей в месяц, то можете рассмотреть следующий план GrowBig, стоимость которого начинается с 5,95 долл./месяц. Место здесь 20 Гбайт, на один год предоставляется бесплатный сертификат SSL, а также предоставляется «приоритетная» техническая поддержка.

Следующий тарифный план GoGeek хорошо подойдёт для 100 000 посещений в месяц и более. Его стоимость начинается от 11,95 долл./месяц. Тариф включает в себя 30 Гбайт дискового пространства, все функции других тарифов, а также дополнительные функции, такие как меньшее количество учетных записей, совместно использующих ваш сервер на shared хостинге, и более совершенное оборудование для повышенной производительности.

 

Namecheap

Namecheap является одним из лучших вариантов для новичков, которые только начинают своё знакомство с иностранными хостингами для сайтов. Стоимость стартового тарифного плана Stellar здесь самая низкая из конкурентов и начинается с 2,88 долл./месяц.

За эту цену вы получаете 20 Гбайт места на жестких дисках, неограниченную пропускную способность, до 3 доменов и 50 поддоменов, cPanel для управления сайтами, 50 учетных записей электронной почты, поддержку CloudFlare и дополнительное программное обеспечение, если есть необходимость.

Следующий тарифный план Stellar Plus за 4,88 долл./месяц. снимает все ограничения стартового тарифа. Последний тариф в линейке Shared хостинга прежде всего подойдёт для бизнес-сегмента. Все ключевые функции для размещения корпоративного сайта или небольшого интернет-магазина тариф Stellar Business предлагает за 8,88 долл./месяц.

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

---

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

Мы желаем Вам выбрать надёжного провайдера услуг для своего сайта.

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

Установка Mercurial на shared-хостинг / Habr

За все время опыта веб-разработки приходилось сталкиваться с различными хостингами на которых работали сайты: от тех, на которых поддерживаются только текстовые форматы (а-ля narod.ru) до виртуальных машин, на которых есть root доступ.

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

Задача была выполнена, и как она была решена — пошагово описано ниже.

1. Доступ к shared хостингу должен выполнятся по ssh. Подключаемся к хостингу:

$ ssh user@host

2. Зайти в домашнюю директорию. Все действия будут выполнятся относительно неё:

$ cd ~

2. Проверяем, что на shared хостинге установлен python:

$ python --version
Python 2.6.6
$

4. Создаем директорию python, для того чтобы там разместить модули, которые потребуются для работы mercurial, но которых нет на shared хостинге:

$ mkdir -p python

5. Скачать исходный код Mercurial:

www.mercurial-scm.org/release

$ wget https://www.mercurial-scm.org/release/mercurial-3.7.tar.gz 

6. Извлечь содержимое архива в текущую директорию:

$ tar xvf mercurial-3.7.tar.gz

7. Переименовываем папку в mercurial:

$ mv mercurial-3.7 mercurial -v

8. Перейти в папку mercurial:

$ cd mercurial

9. Устанавливаем mercurial из исходных кодов:

$ python setup.py --pure build_py -c -d . build_ext -i build_mo --force

10. Так как установка из исходных кодов считается нестандартной то необходимо проделать следующее для установки модулей:

$ python setup.py --pure install --prefix ../../python --force

11. Если установка прошла корректно, то в директории ~/python/lib{type}/python{version}/site-packages/ будет следующий список файлов:

$ ls -l ~/python/lib64/python3.7/site-packages/
total 12
drwxr-xr-x 5 user group 4096 Oct  2  2014 hgext
drwxr-xr-x 6 user group 4096 Oct  2  2014 mercurial
-rw-r--r-- 1 user group 238 Oct  2  2014 mercurial-3.7-py3.7.egg-info
$

А в директории ~/python/bin/ будет содержатся скомпилированный hg:

$ ls ~/python/bin/ -l 
total 4
-rwxr-xr-x 1 user group 770 Oct  1  2014 hg
$ 

12. Создаем файл .profile или .bash_profile (зависит от настроек shared-хостинга), если такового нет:

$ touch ~/.profile

13. В файл записываем следующее:

export PATH=~/python/bin:$PATH
export PYTHONPATH=~/python/lib64/python3.7/site-packages

Первая строка добавляет в переменную окружения PATH путь к папке с Mercurial. Вторая строка добавляет путь к модулям python. Добавление этих строк позволяет работать с Mercurial в интерактивном режиме.

14. Для проверки, что все сделано корректно необходимо создать новое подключение ssh и проверить работоспособность Mercurial:

$ hg --version

Если все сделано верно, то будет показано сообщение вида:

Mercurial Distributed SCM (version 3.7)

Copyright (C) 2005-2016 Matt Mackall <[email protected]> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
15. Для работы Mercurial в не интерактивном режиме необходимо добавить файл .bashrc:

export PATH=~/python/bin:$PATH
export PYTHONPATH=~/python/lib64/python3.7/site-packages

После сохранения изменений необходимо попробовать выполнить команду в не интерактивном режиме:

$ ssh user@host hg --version 

Если будет показано сообщение вида:

Mercurial Distributed SCM (version 3.7)

Copyright (C) 2005-2016 Matt Mackall <[email protected]> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
, то настройка завершена.

Если будет сообщение вида:

sh: hg: command not found

Это говорит о том, что shared-хостинг не позволяет пользователю переопределять .bashrc.

Можно передать нужные переменные окружения непосредственно при выполнении команды в не интерактивном режиме:

$ssh user@host "export PATH=~/python/bin:$PATH;declare -x PYTHONPATH=~/python/lib64/python3.7/site-packages;hg --version"

Должно быть показано сообщение вида:

Mercurial Distributed SCM (version 3.7)

Copyright (C) 2005-2016 Matt Mackall <[email protected]> and others
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
При работе с удаленным репозиторием размещенном на shared-хостинге наличие переменных окружения требуется для команд выполняющих подключение к удаленному репозиторию:

• clone
• outgoing
• incoming
• pull
• push

Для подключения необходимых переменных окружения необходимо воспользоваться опцией —config, добавив путь к hg:

$ hg --config ui.remotecmd='export "PATH=~/python/bin:$PATH";export "PYTHONPATH=~/python/lib64/python3.7/site-packages";~/python/bin/hg' inc

Либо указать эту настройку в .hg/hgrc в секции [ui]:

[ui]
config ui.remotecmd = export "PATH=~/python/bin:$PATH";export "PYTHONPATH=~/python/lib64/python3.7/site-packages";~/python/bin/hg

При таких настройках удаленная команда может не выполнится, из-за наличия кавычек.

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

alias hg="hg --config ui.remotecmd='export "PATH=~/python/bin:$PATH";export "PYTHONPATH=~/python/lib64/python2.6/site-packages";~/python/bin/hg'"

После этого можно выполнять команды в привычном виде:

$ hg inc

Ссылки на использованные материалы:

1. Installing Mercurial on a Shared Web Server without Root Access
2. Installing Python Modules
3. Python Windows Install (Описание для Windows, но Windows тут не использовался)
4. Mercurial — CommonProblems
5. Configuration files for Mercurial
6. Linux man page — bash

Различия в работе услуг shared-хостинга и виртуального сервера — Помощь

5.1. Различия в работе услуг shared-хостинга и виртуального сервера

При использовании услуги shared-хоситнга у клиентов есть доступ только к своему пользователю и вся работа происходит на уровне пользователя. Все клиенты размещаются на хостинг-сервере и делят его мощности. На shared-хостинге присутствуют различные ограничения и лимиты, например по отправке почты, лимиты по работе с базами данных, по нагрузке. В следствии чего довольно много различного ПО на хостинге размещать нельзя и/или оно попросту не будет работать там корректно.

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

Если Вы никогда не пользовались услугами виртуального сервера, а только хостингом и не знаете как с ним работают — ну уровне пользователя панель управления ISP такая же, как и на нашем хостинге.
Чтобы войти под пользователем — в разделе «Пользователи», как на рисунке выше, нажмите на нужного пользователя и нажмите иконку «Войти».

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

Но VPS/VDS ограничен в ресурсах, и имеет четкий предел возможностей согласно выбранного тарифного плана. Это также стоит учитывать при выборе и заказе сервера. К примеру, тарифный план «Старт» с 256 мб ОЗУ не рассчитан на ресурсоемкие задачи, а скорее предназначен для статичных сайтов и ознакомления с панелью управления сервером. Но в любом случае, после заказа сервера Вы всегда можете в течении пары минут сменить тарифный план вашей услуги, если текущий тарифный план не будет Вам подходить. Как менять тарифный план описано в данной статье

При заказе виртуального/физического сервера у Вас будет собственный выделенный IP адрес, и данным IP будете пользоваться только Вы. Что убережет от ситуаций когда на shared-хостинге из-за какого-то клиента славшего спам на этом же IP, он попадет во внешние черные списки DNSBL и почта временно перестанет работать у всех на этом IP.

Но все вышесказанное абсолютно не означает что VPS/VDS лучше виртуального хостинга или наоборот. Все зависит от поставленных задач. Если Вы просто хотите разместить ваш сайт либо только начинаете заниматься разработкой сайта, вероятно стоит заказывать услугу shared-хостинга либо Премиум хостинга.
Если же Вы хотите установить, к примеру, панель управления/статистики игровыми серверами — Вам следует выбрать услугу VPS/VDS.

Поучительная история о том, что может случиться с сайтом на shared-хостинге / Habr

Рабочий день медленно, но уверенно подходил к концу. Солнечный свет струился сквозь жалюзи и заливали офис золотистым багрянцем. Где-то в углу жужжала кофемашина, выдавливая остатки кофе из капсулы. Наш проджект что-то оживлённо обсуждала с дизайнером, а я правил косяки, любезно оставленные мне младшим программистом.
И всё вроде бы ничего, если бы не сообщение: «А что у вас с сайтом T?».

Один мой хороший знакомый заметил, что один из наших сайтов отображается некорректно и дал мне знать.
Я отбросил все дела и загрузил страничку с сайтом. Никаких проблем на ней не наблюдалось. Ну, разве что требовался небольшой редизайн…
«С сайтом всё в порядке» — написал я знакомому и снова погрузился в увлекательный мир кода и багов.
Через некоторое время, мой мозг всё же вынул из памяти тревожный сигнал моего знакомого и я невольно полез повторно проверять сайт. Отчего-то уверенный в работоспособности сайта, я испытывал лёгкую самоуверенность.
Главная страница сайта, уныло встретила меня сбившейся кодировкой и полным отсутствием css. Черные символы абракадабры на девственно-белом фоне вернули меня в реальность. Самоуверенность моментально улетучилась и я начал лихорадочно вдавливать CTRL+F5 в клавиатуру.
«Это просто кэш… Да… Просто кэш…» — повторял я себе раз за разом.

Когда я осознал, что моя десятая по счёту попытка сбросить кэш браузера не даёт никаких результатов, а главная страница сайта продолжает изменять своё обличие с каждым нажатием на заветные клавиши, первое, что пронеслось в моей голове — «Взлом?!». Мои опасения начали крепнуть, когда после очередной перезагрузки страницы, я увидел красную по белому надпись, в которой говорилось, что такая-то таблица не была найдена.
Руки сами пустились менять все, имеющие отношение к сайту, доступы: админка, база данных, SSH.
После, я начал внимательно изучать логи. Хотя, логи — это громко сказано. В моем распоряжении были только отчеты по работе веб-сервера. Журналы сбоев MySQL и неудачных попыток авторизации через SSH, на shared-хостинге не выдают.
Ничего странного в логах небыло выявлено и я направился прямиком в SSH консоль для того, чтобы соединиться с MySQL напрямую, ведь я отчетливо помню, что сайт ругался на отсутствие таблиц в базе данных.
Очень странно, но все таблицы были на месте (по крайней мере те, на которые ругался сайт, точно были на месте).
В качестве CMS, на сайте T, используется 1С-Битрикс. Мы очень любим эту систему и всячески ею восторгаемся (за редким исключением).
Каково же было мое удивление, когда, зайдя в настройки сайта, я увидел данные от совершенно постороннего сайта R. Путь к корню, имя домена и некоторые другие настройки — были изменены. Я, остолбеневший, смотрел в монитор круглыми от удивления глазами. В то же время, где-то позади меня, наш проджект уже разливала настойку валерьяны. Я зачем-то нажал F5. То, что произошло после этого, повергло меня в глубочайший шок и уныние. Настройки сайта вновь приняли нормальные значения.
В этот момент, я на мгновение усомнился в адекватности всей IT-индустрии в целом и начал верить в чудеса. Телефонный звонок супруги вывел меня из ступора. Я поднял трубку. До сих пор не могу вспомнить о чем она мне говорила, так как ощущение чего-то загадочного не покидало меня и мой мозг лихорадочно пытался найти хоть какое-то объяснение случившемуся.
Я что-то буркнул в трубку и дал отбой. Ну теперь, я хотя бы в чем-то уверен. Уверен, что дома меня ждет много интереснейшей информации о самом себе.
Но это потом, а сейчас надо понять — что происходит.

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

Вот и в этот момент наш педантичный надзиратель неумолимо отсчитывал время с каждым шагом секундной стрелки.
А мы всё ждали, что вот-вот, уже сейчас, наш почтовый сервер примет долгожданный ответ от какой-нибудь из тех.поддержек.
Но письма всё не было. Ни о какой работе и речи быть не могло. Мой мозг, гоняя серое вещество, пытался разгадать эту странную метаморфозу с сайтом T.
Понимая, что если сайт в таком состоянии увидят его посетители, они явно не обрадуются, я полез закрывать его от общего доступа. Тем более, если имеет место взлом, то вполне возможно, что сайт уже полон инъекций, с целью кражи cookie-файлов, а значит, посещение данного сайта абсолютно противопоказано.
После нажатия заветной кнопки в настройках главного модуля, сайт погрузился в анабиоз.
Я, из любопытства, зашел на сайт R, чьи настройки были прописаны в настройках нашего сайта.
«Site Under Construction» — красовалось на главной странице сайта R.
Мозг попытался установить связь между двумя последними событиями и я снова открыл доступ к сайту T.
Вновь зайдя на сайт R, я увидел, что и он восстановил свою работоспособность.
Совпадение или зависимость?
Повторив манипуляции в настройках главного модуля, я убедился, что здесь имеет место зависимость сайта R от нашего сайта T и наоборот.
Но как такое может быть?
Всё, чем связаны сайты T и R — это хостинг.

«А давайте позвоним по телефону, указанному на сайте R и попытаемся объяснить им ситуацию» — неожиданно для всех предложила наш проджект.
Не успели мы ощутить всю гениальность этой идеи, как вдруг в офисе раздался телефонный звонок.
На том конце трубки были ребята, которое разрабатывали сайт R и в данный момент тоже находятся в недоумении от происходящих событий.
Мне передали трубку.
После недолгого разговора, выяснилось, что они, так же как и мы, понятия не имеют о причинах происходящего.
«Видимо на хостинге, каким-то непонятным образом, имеется символическая ссылка между двумя нашими базами» — предположил я.
Ну а какое еще объяснение тут можно было найти? Доступы к обоим базам — разные, но, каким-то странным образом, изменения в их базе данных, влияют на нашу и наоборот.
«Вы пробовали создать другую базу данных?» — продолжал я.
«Да, это уже третья» — с грустью в голосе ответили мне на том конце трубке.
Таким образом, вариант с символической ссылкой не выдерживал никакой критики.
Те ребята тоже написали обращение в тех.поддержку Хостинга. Мы обменялись именами, скайпами и телефонами, условившись держать друг-друга в курсе событий.
Вестей от тех.поддержки Хостинга всё не было. Я вновь набрал их номер и начал объяснять сотруднику тех.поддержки, что ситуация патовая и одна и та же проблема наблюдается уже на двух аккаунтах Хостинга.
Ничего внятного в ответ я так и не услышал. По окончанию бессмысленного и безрезультатного разговора, я окончательно убедился в том, что тех.поддержка Хостинга нам точно не поможет.
Ну, по крайней мере было ясно, что это не взлом.
С этого момента, я перестал надеяться на тех.поддержку Хостинга и взял всё в свои руки.

Что-то подсказало мне, что я получу ответы на свои вопросы, зайдя в список таблиц через админку 1С-Битрикс. Ну на самом деле, других вариантов откуда можно было бы начинать поиски, не было.
Я был удивлен не менее прежнего, когда обнаружил, что содержимое таблицы b_lang (где хранятся настройки сайтов) и содержимое админской страницы настроек сайта — разнятся.
Что за чертовщина?! Как такое может быть?!
«Их два!» — мелькнуло у меня в голове.
«Соединений с базой данных — два» — я всё больше укреплялся в этой мысли.
Как иначе объяснить, что админка показывает одно, а содержимое таблиц — другое?
Еще немного развив эту идею, я вспомнил про постоянные соединения с базой данных.
Хотя, судя по описанию технологии постоянных соединений, они разграничены как минимум именем пользователя и паролем при подключении к базе, а эти данные у сайтов R и T — разные.
И все-таки, может ли система кэширования как-то запомнить соединение и отдавать его при двух абсолютно разных подключениях?
К этому моменту я уже готов был поверить во всё, что угодно.
Я отключил функцию постоянных соединений в настройках 1С-Битрикс и, заодно, тип кэширования оставил пустым (до этого там стояло значение — «APC»).
То же самое я попросил сделать и моих коллег по несчастью.
Когда всё было готово, я нажал F5. Это были самые долгие и волнительные секунды моей жизни. Ну не может быть всё так просто.
Наконец страница загрузилась и… сайт заработал! У сайта R тоже всё было в порядке. Был только один способ проверить, всё ли нормально. Я зашел в настройки главного модуля и снова отправил сайт в состояние «Under Construction». Сайт T, послушно последовал данному указанию, а сайт R оставался в рабочем состоянии. Этот факт говорил нам о том, что проблема успешно решена и базы больше не связаны между собой.
Но в чем же проблема? В постоянных соединениях или в кэшировании?
Удалось выяснить, что проблема заключалась в том, что у сайтов, которые вообще никак не связаны между собой, перемешался APC-кэш.

1С-Битрикс, в файле dbconn.php, принудительно кэширует следующие таблицы:

• b_file
• b_file_bucket_size
• b_lang
• b_option
• b_lang_domain
• b_site_template
• b_event
• b_agent

Список может отличаться.
Среди прочих таблиц, здесь отчетливо видна та самая b_lang, где хранятся настройки сайтов. Следовательно — сайты T и R попеременно записывали данные в эту таблицу и кэшировали ее в APC. Когда сайт R кэшировал таблицу, сайт T брал закэшированную копию и наоборот.
Но вот самый главный вопрос — как возможно на хостинге, с тысячами работающих аккаунтов, смешивание кэша?
Ведь получается, что любой сайт, использующий APC, может нарушить работоспособность любого (почти) другого сайта (так же использующего APC), в пределах данного хостинга (точнее сервера).
Как следствие — убытки из-за простоя сайтов и, возможно, кража данных, ведь закэшировать можно всё, что угодно.
Неужели такая логика работы хостинга является нормальной?
После недолгой дискуссии с разработчиками сайта R, мы пришли к выводу, что можно просто выставить разный BX_CACHE_SID для наших сайтов.
Очевидно, что есть определенная проблема, так как сайт T проработал на данном Хостинге около полутора лет и никаких нареканий подобного характера не вызывал. А тут вдруг такой казус.

Почему именно с сайтом R смешался наш кэш?
Почему не предусмотрено никаких механизмов разграничения кэша разных аккаунтов на таком большом хостинге?
С этими вопросами я отправился домой. Они не уходили из моей головы до самого вечера.
У порога я был радушно встречен, уже успевшей соскучиться по мне, супругой, а на столе стоял горячий и аппетитно пахнущий ужин.
«Это недоразумение закончилось» — подумал я с облегчением.
Да, когда-нибудь мы обязательно займемся играми…

UPD 1: обдумав комментарии, пришел к выводу, что необходимо подвести краткое резюме по всему вышесказанному
Всегда выставляйте уникальный ID кэша и регулярно делайте бэкапы

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

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

Виртуальные шаред хостинги / Web.ABCD.bz

Адрес для России — Москва, Мясницкая 25, оф. 451
Принимают безнал по запросу.
Стандартные методы оплаты — Робокасса и Z-pay

Оффшорный адрес: Fujitsu Denso International Limited Tel: +852-2828-2850
Address: 9/F. Lincoln House, 979 King’s Road, Taikoo Place, Island East, Hong Kong

Их хостинг на платформе NodeSquad.

Вместо ftp(передает ваши фтп пароли в открытом виде) по умолчанию используют для всех sftp(это ftp over ssh потому пароли никто перехватить или подсмотреть не сможет). И многие другие изменения, читайте faq на сайте.

Используют Дата-центр Hetzner.

Имеют партнерский аккаунт регистрации доменов через reg.ru http://reg.nodesquad.com/login.php?ret=%2F

Кол-во серверов я не понял. Ну штук 3-5 думаю, стандартных Hetzner-ских дешевых, мощных серваков на 32/64 оперативки.
node1-2.whitesuite.ru/manager/ispmgr (но node1-1 node1-3 и последующие не существуют)
node24-1.whitesuite.ru/manager/ispmgr (тоже node24-2 node24-3 node10 node15 и т.д. не существуют)
SSL сертификаты куплены отдельно — на поддомены, а не на весь домен whitesuite.ru, поэтому думаю — серверов не особо много, т.к. куда дешевле купить 1 сертификат на домен с поддоменами, чем 10 сертификатов на 10 поддоменов. Поэтому цифра явно меньше 10.

Что хочу еще отметить — куплен для серваков у них Гигабитный канал. Это хороший плюс. Многие покупают сервера и не модифицируют их, не добавляют ни ssd для ОС, ни флеш-накопителей для бекапов ОС. Ни каналы не расширяют. А эти канал продумали.

Пока изучал обсуждения/историю на форуме. Видел, что в 2011 был косяк с dns, как у всех бывает по первости, если домен куплен в .ru зоне и оформлен не на ЮЛ. Физиков в .ru легко локают, тем более не особо крупного уровня 😉
И видел что после того случая они сделали резервный домен whitesuite.net
И я подумал, что DNS у них стали по уму, на 2х разных доменах, если локается один, то второй дублирует. НО увы.
Щас заказал тестовый период — вижу ns01.whitesuite.ru. ns02.whitesuite.ru.
Хотя — нада бы сделать ns.whitesuite.RU ns.whitesuite.NET = и будет идеально 😉

Это всяким конторам типо ihc.ru можно не беспокоиться, где правовые вопросы решены, где имеется лицензия, ЮЛ и все остальное. А всем остальным — всегда нада готовиться, что когда-ниб их залочат.

В итоге. Довольно интересный хостинг получился.

• 1 сайт — 500 мб — 22р
• 2 сайта — 1 ГБ — 44р
• 3 сайта — 1,5 ГБ — 66р
• 5 сайтов — 2,5 ГБ — 110р
• 10 сайтов — 5 ГБ — 220р
• 15 сайтов — 7,5 ГБ — 330р
• 20 сайтов — 10 ГБ — 400р
• 30 сайтов — 15 ГБ — 660р
• 40 сайтов — 20 ГБ — 800р
• 50 сайтов — 25 ГБ — 1100р

Можно купить выделенный ip за 4 евро/мес. Вот такой шаред хостинг, на nodesquard, с помощью которой его можно считать vip-хостингом. Притом он старается не собирать мусор, правила четко прописаны.