Облачный хостинг – что это и какие его преимущества. Шаред хостинг
| Март | 500 МБ | 1 | 1 | 1 | ∞ |
Франция
ISPmanager PHP SSL IPv6 |
500 МБ / 1 сайт / 1 база данных / 1 ящик
Франция ISPmanager PHP SSL IPv6 |
19 руб. |
|
500 МБ / 1 сайт / 1 база данных / 1 ящик
Франция ISPmanager PHP SSL IPv6 |
||||||||
| Микро | 100 МБ | 2 | 2 | 2 | ∞ |
Россия
ISPmanager PHP SSL |
100 МБ / 2 сайта / 2 базы данных / 2 ящика
Россия ISPmanager PHP SSL |
22 руб. |
|
100 МБ / 2 сайта / 2 базы данных / 2 ящика
Россия ISPmanager PHP SSL |
||||||||
| Визитка | 350 МБ | 1 | ∞ | ∞ | ∞ |
Россия, США, Франция
DirectAdmin PHP SSL 3 месяца |
350 МБ / 1 сайт / ∞ баз данных / ∞ ящиков
Россия, США, Франция DirectAdmin PHP SSL 3 месяца |
25 руб. |
|
350 МБ / 1 сайт / ∞ баз данных / ∞ ящиков
Россия, США, Франция DirectAdmin PHP SSL 3 месяца |
||||||||
| Iron | 500 МБ | 1 | 0 | ∞ | ∞ |
Украина
ISPmanager PHP SSH SSL IPv6 |
500 МБ / 1 сайт / 0 баз данных / ∞ ящиков
|
28 руб. |
|
500 МБ / 1 сайт / 0 баз данных / ∞ ящиков
Украина ISPmanager PHP SSH SSL IPv6 |
||||||||
| Sport S | 250 МБ | 1 | 0 | ∞ | ∞ |
Германия, Франция
cPanel PHP SSL 6 месяцев |
250 МБ / 1 сайт / 0 баз данных / ∞ ящиков
Германия, Франция cPanel PHP SSL 6 месяцев |
29 руб. |
|
250 МБ / 1 сайт / 0 баз данных / ∞ ящиков
Германия, Франция cPanel PHP SSL 6 месяцев |
||||||||
| Базовый | 1000 МБ | 1 | 1 | 1 | ∞ |
Франция
ISPmanager PHP SSH SSL IPv6 |
1000 МБ / 1 сайт / 1 база данных / 1 ящик
|
29 руб. |
|
1000 МБ / 1 сайт / 1 база данных / 1 ящик
Франция ISPmanager PHP SSH SSL IPv6 |
||||||||
| Микро | 300 МБ | ∞ | ∞ | ∞ | ∞ |
Украина
DirectAdmin PHP SSL |
300 МБ / ∞ сайтов / ∞ баз данных / ∞ ящиков
Украина DirectAdmin PHP SSL |
29 руб. |
|
300 МБ / ∞ сайтов / ∞ баз данных / ∞ ящиков
Украина DirectAdmin PHP SSL |
||||||||
| Эгоист | 150 МБ | 1 | 1 | 10 | ∞ |
Германия
ISPmanager PHP SSL 12 месяцев |
150 МБ / 1 сайт / 1 база данных / 10 ящиков
|
30 руб. |
|
150 МБ / 1 сайт / 1 база данных / 10 ящиков
Германия ISPmanager PHP SSL 12 месяцев |
||||||||
| Блог | 200 МБ | 3 | 3 | ∞ | 20 ГБ |
Россия
ISPmanager, cPanel, DirectAdmin PHP SSL IPv6 |
200 МБ / 3 сайта / 3 базы данных / ∞ ящиков / 20 ГБ
Россия ISPmanager, cPanel, DirectAdmin PHP SSL IPv6 |
30 руб. |
|
200 МБ / 3 сайта / 3 базы данных / ∞ ящиков / 20 ГБ
Россия ISPmanager, cPanel, DirectAdmin PHP SSL IPv6 |
||||||||
| Site | 200 МБ | 1 | 1 | 20 | ∞ |
Украина
|
200 МБ / 1 сайт / 1 база данных / 20 ящиков
Украина ISPmanager PHP SSL 6 месяцев |
30 руб. |
|
200 МБ / 1 сайт / 1 база данных / 20 ящиков
Украина ISPmanager PHP SSL 6 месяцев |
||||||||
| Доступный | 1000 МБ | 1 | 2 | ∞ | ∞ |
Германия
ISPmanager PHP SSL |
1000 МБ / 1 сайт / 2 базы данных / ∞ ящиков
Германия ISPmanager PHP SSL |
32 руб. |
|
1000 МБ / 1 сайт / 2 базы данных / ∞ ящиков
Германия ISPmanager PHP SSL |
||||||||
| Доступный | 1000 МБ | 1 | 2 | ∞ | ∞ | cPanel PHP SSL |
1000 МБ / 1 сайт / 2 базы данных / ∞ ящиков
Нидерланды cPanel PHP SSL |
32 руб. |
|
1000 МБ / 1 сайт / 2 базы данных / ∞ ящиков
Нидерланды cPanel PHP SSL |
||||||||
shared.menu
Shared Hosting vs Облака / Хабр
Давайте сравним shared hosting и облачную систему хранения данных. Для начала — вспомним одну любопытную и достаточно основополагающую историю из общего курса экономики. В 70-х годах прошлого века, один предприимчивый человек, будущий лауреат Нобелевской премии, Джордж Акерлоф описал новаторскую модель экономики. Он назвал ее — «Рынок лимонов», заранее давая понять, о чем она будет.Итак, что он сделал? Он рассмотрел рынок подержанных автомобилей. Как и сейчас, 40 лет назад на этом рынке продавались не только те автомобили, хозяева которых лелеяли и заботились о своих машинах, но и те, которые были в достаточно плохом состоянии. Именно последние и получили название «лимонов». Вся модель упиралась в один важный факт — покупатель никогда до конца не знает, покупает ли он «лимон» или хороший добротный автомобиль.
Это же правило очень хорошо работает и, например, с shared хостингами. Много памяти в пакете? Получите в довесок медленные SATA диски. SSD хостинг? В довесок процессор на Atom. И прочие неприятные комбинации. Если мы не указываем конкретных параметров отбора по необходимым нам критериям — то, согласно «закону лимонов» мы получаем неликвид по критериям, которые мы забыли.
Чем же нам это грозит в случае облачных сервисов?
Параметры, которые нам действительно должны быть важны — это тактовая частота процессора, скорость шины, тип памяти, объем и ECC. Но что мы видим в описаниях? Объём места (без iops), количество ядер (каких ядер?), объём ОЗУ… Выходит, что мы видим лишь «маркетинговые» параметры, которые, на самом деле, никакой погоды не делают. А это значит, что большинство попыток сравнить облачные сервисы в лоб (например, по прайсу) — обречены на провал или махинацию. Вот она — победа маркетинга в IT! Мы перестали смотреть в суть облака, а лишь меряем маркетинговые величины.Давайте разберем это на примере провайдера. Скажем, я региональный провайдер, имеющий 1гб выделенный канал. Я продаю его двадцати пользователям — как гигабитный (или пятидесяти пользователям, как повезёт). Если все они одновременно не включат торрент, способный забить весь канал, то никто и не заметит, что гигабит давно коммунальный, а не его личный.
То же самое делает и shared hosting — продавая место и память. На самом же деле, далеко не все сайты постоянно кто-то смотрит — и, в итоге, они могут продать один сервер шесть/семь раз.
Примерно так же работает и «облако». Переход к условным единицам позволяет нам потерять из виду реально потребляемые ресурсы и начать измерять мир «в попугаях». Эта же система позволяет продать нам один сервер несколько раз. И из-за этого мы получаем ещё одну неизвестную переменную в работе с облаком.
habr.com
боль и страдания или простая рутина? / Хабр
Коротко для тех, кто спешит
Утилита FTP Deployment: написана на php, принимает в качестве параметра путь к конфигу и выкладывает файлы на удаленный сервер, довольно быстро и хорошо.Долго и подробно для тех, кому интересно
Все мы любим классные и удобные методы деплоя с помощью capistrano, rsync или, на худой конец, git pull. А если надо выкладывать проекты на shared-хостинг?Однажды я вдруг понял, что привык к хорошему, и ненавижу выкладывать проекты через (S)FTP: не залился какой-то файл; надо вспомнить, где лежат конфиги; вот эту папку не надо выкладывать вообще; вот тут надо проверить права. Думаю, многие этот список легко продолжат.
Тут еще надо сказать, что я с большим удовольствием пользуюсь символическими ссылками для минимизации места (и автоматической актуализации кода). Небольшой shell-скрипт создает контекст нового проекта, в котором уже есть библиотеки, ядро, статика и docroot с htaccess. Мне остается положить правильные конфиги и настроить всё “под клиента”.
В старые времена всё это я делал на своей локальной системе, а потом с помощью FileZilla или GnomeCommander заливал на хостинг. Сейчас перешел на небольшой выделенный сервер, и пришлось искать решение. Хотелось готовое и простое — и я его нашел!
С помощью FTP Deployment выкладка из долгого муторного занятия превращается в одну команду. Ну, на самом деле, в две — тестовый запуск никто не отменял:).
Первый этап: в папку проекта (или в любое удобное место) нужно поместить конфиг утилиты. Ini или php — на ваш выбор. Позволю себе перевести на русский комментарии в примере.
[my site] ; Может быть несколько секций ; удаленный FTP-сервер remote = ftp://user:[email protected]/directory
; пассивный режим FTP passiveMode = yes
; локальный путь (опционально, но я обычно указывают абсолютный путь вроде /var/www/production/project_path/) local = .
; тестовый режим? (можно включить опцией -t или --test) test = no
; Список игнорируемых файлов и каталогов ignore = " .git* project.pp[jx] /deployment.* /log temp/* !temp/.htaccess " ; Удалять файлы на сервере? (по умолчанию -- да) allowDelete = yes
; скрипты, которые надо запустить до загрузки before[] = http://example.com/deployment.php?before
; скрипты, которые надо запустить после загрузки afterUpload[] = http://example.com/deployment.php?afterUpload
; скрипты, которые будут запущены в конце after[] = http://example.com/deployment.php?after
; каталоги, которые надо очистить после загрузки purge[] = temp/cache
; файлы для предобработки (по умолчанию -- *.js *.css) preprocess = no
; Файл, в котором будут контрольные суммы загруженных файлов deploymentFile = .deployment
В общем-то, всё достаточно очевидно и понятно. Readme проясняет некоторые неясности.
Например, в игнорируемых файлах pp[jx] — означает и ppj и ppx. Восклицательный знак — исключение из предыдущей строчки. В примере — всё, что находится в temp мы не загружаем. Но папку создаем и temp/.htaccess в нее загружаем.
И, наконец, про препроцессор. Утилита может сжимать css с помощью YUI Compressor, а js — с помощью Google Closure Compiler. Оба инструмента в дистрибутиве, но требуют Java.
Когда конфиг готов, можно провести тестовый запуск.
php deployment.php deployment.ini -t Утилита расскажет, что она собирается делать и с какими файлами. Если вы сомневаетесь в списке игнорируемого — самое то.Если всё хорошо — можно деплоиться:
php deployment.php deployment.iniПоначалу внимательно читайте, что вам напишет тестовый запуск. По очевидным причинам нельзя закачивать на сервер ftp-deployment.ini. Ну, и вообще, у кого-то и config.php.bak в проектах болтается…
Мне утилита очень понравилась, с удовольствием пользуюсь и друзьям советую. Если знаете удобные альтернативы на других языках — буду благодарен.
habr.com
Shared хостинг и VPS, в чем ключевая разница?
Многие владельцы интернет-ресурсов, выбирая где размещать свои веб-приложения, задумываются что же лучше в их конкретном случае - виртуальные сервера или же shared-хостинг.Предлагаю детально рассмотреть обе услуги и сделать в конце выводы о том, какой из этих услуг можно отдать свое предпочтение и при каких обстоятельствах.
Предположим, что у Вас есть веб-сайт или планы его создать. Вы обратились к специалисту, который знает с помощью каких технологий разрабатывать сайт. Вероятней всего, он уже имеет личное представление на каком хостинге его разместить, и предложит ресурс из своих собственных наработок. Но Вы любите сами во всем разбираться, и поэтому, чтобы добраться до истины, предпочитаете озадачиться поиском надёжного и действительно подходящего веб-хостинга. Того самого ресурса, который и определяет, как Ваш сайт будет размещен в Интернете.
VPS\VDS. Эти аббревиатуры встречаются довольно часто - одни пишут VPS, другие используют VDS. Оба понятия появились примерно в одно время и на самом деле означают одно и то же. VPS (Virtual Private Server) или VDS (Virtual Dedicated Server) – виртуальный выделенный сервер.
Физический сервер. Это такой же компьютер, как и у Вас дома, и порой более мощный. Для физических серверов используются процессоры из специальной серии, которые стоят дороже, чем для большинства домашних компьютеров. Вместе с памятью специального типа такие процессоры гарантируют точное выполнение программ. Кроме этого, в серверах могут применяться видеокарты которые нужны под специфические задачи и по большей части архитекторам.
Виртуализацией называют технологию, которая запускает на одном физическом компьютере несколько изолированных друг от друга виртуальных машин. Для того, чтобы осуществлять виртуализацию, необходимы технические средства. На каждый физический сервер (у провайдера их могут быть сотни) устанавливается гипервизор. Сервера объединяются в кластер, руководит кластером сервер управления.
Для того, чтобы создать в описанной инфраструктуре много виртуальных дата-центров и отдать управление конечному клиенту, используется специальная программа, позволяющая управлять виртуальными машинами, виртуальными сетями и виртуальным коммутатором.
Исторически первыми на рынке появились shared-сервера VPS. Они были построены, как правило, на базе Linux upstream containers. Каждый клиент на таком хостинге получает изолированный контейнер для размещения своих файлов и приложений. При этом пользователь имеет доступ с ограниченными правами в пределах своего VPS.
Сегодня эта технология уже устаревает, и со временем ее полностью заменит облачный VPS, который имеет ряд преимуществ:
- Виртуальные машины (ВМ) пользователей независимы – исключено влияние одного пользователя на других;
- Каждая ВМ может использовать свою ОС;
- Клиент получает полный административный доступ внутри ВМ и может устанавливать любое ПО;
- ВМ можно переносить между серверами и экспортировать\импортировать;
- При аварии физического сервера ВМ сразу запускаются на других серверах;
- При высокой нагрузке на физический сервер ВМ перемещаются на менее загруженные сервера.
Shared-хостинг - это, как правило, совсем простой тип хостинга. На сервере провайдера устанавливается набор приложений – web-сервер, СУБД, PHP, и тп. Каждому пользователю доступна папка для размещения файлов и панель управления, из которой он может выполнить настройки предоставляемых частей web-сервера и СУБД для нужд работы сайта. Преимущество такого хостинга – низкая стоимость и простота.
Минусы:Проекты пользователей сильно влияют на производительность. Если одному сайту потребуется больше ресурсов, то другие сайты на хосте могут работать ощутимо медленнее;При аварии физического сервера все сайты клиентов, размещенные на нём, не работают;Нельзя установить своё ПО и библиотеки.
На самом деле многие на себе убедились, что виртуальный сервер работает также, как и физический. Потеря производительности из-за наличия гипервизора составляет не более 5% в сравнении с аналогичным физическим сервером. При необходимости размер ресурсов, выделенных виртуальной машине, может быть изменен в один клик.
Shared-хостинг и виртуальный сервер могут выполнять как одни и те же задачи, так и разные. Если на «шаред» размещают только сайты, то на VPS можно запускать высоконагруженные приложения (SAP HANA, базы Oracle, сервер 1С: Бухгалтерии) или обеспечивать работу PHP скриптов.
Из заказанного виртуального сервера, пользователь может сделать при желании свой собственный shared-хостинг. Управлять им можно совместно. Управление происходит как с ПК, так и со смартфона.
К каким же выводам мы пришли:
Как и во всем, сначала нужно определиться, какие у Вас запросы к проекту.Если планируете расти и увеличивать свое влияние в выбранном сегменте, то необходимо остановиться на виртуальном сервере.Именно с ним Ваш сайт сможет принять больше посетителей одновременно и избежать непредвиденных поломок.В ином случае подойдет и shared-хостинг.
Рекомендуется с самого старта использовать тот ресурс, который наиболее подходит именно для Вашей задачи, чтобы два раза не бегать!;-))
kukmor.livejournal.com
Контейнеризация — новый shared-хостинг / Хабр
Новые решения по виртуализации и контейнеризации вовсю используются разработчиками для тестирования приложений и поддержки инфраструктуры разработки. Но будет ли это новым форматом shared-хостинга?Что я вижу сегодня в shared-хостинге
- Клиенты хотят меньше технических подробностей и хранить все в “облаке”
- По сравнению с тем, что было пять лет назад — нужно меньше магических действий в unix shell, чтобы запустить свое приложение ( появились панельки, контейнеры, простые установщики )
- Появилось множество SaaS и PaaS приложений, которые выполняют все те же функции, что и самостоятельно размещаемые приложения
В качестве решения напрашивается возможность воспользоваться преимуществами контейнеризации. На текущий момент технологии уже готовы к промышленному применению:
- Maas/juju — стек Ubuntu, позволяет управлять множеством географически распределенных физических серверов и запускать приложения из готовых шаблонов.
- Проприетарные облака: Red Hat (OpenShift), VMWare (Cloud Foundry), Google (App Engine)
- Современные решения для shared-хостинга (CloudLinux с изолированными окружениями)
- Docker: решает задачи доставки приложения от клиента на хостинговую платформу и в целом меняет парадигму с «клиент/сайт» на «клиент/приложение», что приближает хостинг к бизнесу. Docker позволяет использовать LXC контейнеры. CRIU (OpenVZ/Parallels) позволяет переносить контейнеры LXC между физическими машинами прозрачно для пользователя
Что получаем в результате?
Контейнеры как основа для шаред-хостинга выгодны самим хостерам. Можно подавать и как традиционный хостинг и как облако, PaaS, SaaS и так далее в зависимости от того, что находится в верхушке новостей. Например, сегодня это Docker, который активно развиваются сообществом.
Использование контейнеров, одинаковых на машине пользователя и на хостинге уменьшает цепочку от принятия решения создать сайт до непосредственно запуска приложения на хостинге и упрощает развертывание и перенос приложения на новый хостинг. Для развертывания сайта или приложения достаточно предоставить текстовый файл описания контейнера и ввести данные кредитки. Это определенно легче, чем заливать файлы через FTP.
Пользователь привязан к компании, потому что технически возможно обеспечить масштабирование в больших пределах, нежели раньше. Для временного решения проблем производительности достаточно перевести контейнер на менее загруженный узел. Благодаря CRIU в большинстве случаев это произойдет прозрачно для пользователя.
Появляется возможность снизить количество машин. Контейнеры могут быть добавлены как на простаивающие сервера, так и на работающие с неполной загрузкой. Появляется возможность быстро вводить в работу и выводить из работы физические сервера. Появляется возможность утилизировать неиспользуемые вычислительные ресурсы другими приложениями, не относящимися к шаред-хостингу.
И наконец, вопрос к хабрасообществу — действительно ли решающим фактором выбора хостинга более технологичная платформа или все решает поддержка и маркетинг?
habr.com
Почему нельзя использовать shared-хостинг. Или очередной холивар на тему «хостеры лохи». « Debian.pro
Все люди, которые со мной общались по поводу «у меня есть проблемасайт и я хочу переехать на другой хостинг» слышали от меня фразу «shared-хостинг? да не, точно мудаки, бери VDS». Пришло время сорвать покровы (раз уж у меня период графомании) и на примерах показать-рассказать, почему в 2015-м году использовать шареды нельзя от слова «совсем». Дабы не быть совсем уж негативным, я сначала расскажу о том, что есть хорошего в shared-ах.- обычно они дешевле VPS/VDS (хотя и с приходом digitalocean/linode/flops и прочих это не всегда так).- чтобы положить файл на shared-хостинг обычно ничего толком не нужно знать. Ну то есть уж знаний в администрировании точно не нужно — достаточно почитать хелп по панели, которую использует хостер.- если вам повезло с саппортом хостера, то вам объяснят, почему ваш код не работает на хостинге.- вам действительно не нужен сисадмин, даже знакомый. Многие хостеры помогают переехать/настроить домен и прочую фиговину, после чего вы забываете про всю механику до тех пор, пока не собираетесь менять хостинг.- обычно в комлекте дают настроенную почту/dns и прочее, так что думать нужно ещё меньшеИ прежде чем начать, хочу сразу оговориться, что есть действительно хорошие хостинги. Правда, они по большей части приватные, стоят от $50 за один сайт, имеют зубров в поддержке и лишены почти всех минусов, описанных ниже. И найти их очень тяжело. Я сталкивался с двумя, ещё про один слышал на тостере, при том те, с кем я взаимодействовал, уже не принимают новых клиентов. И это за почти 10 лет с момента создания первой бесполезной хоумпаги на народе (сайт школы моей, ага). Ну а теперь к делу.1) Первая и самая главная проблема — вы вообще ни на что толком не можете повлиять в настройках. Мне встречались хостеры, где на серверах не были установлены php5-curl и php5-imap. С некоторыми удалось договориться, они поставили эти модули (казалось бы — php без курла?) достаточно быстро. С некоторыми пришлось пободаться и дойти до третьей линии саппорта со скандалами. На одном хостинге удалось (случайно) договориться об установке php5-imap на нужный сервер через тех.дира, с которым удалось пересечься где-то в irc — саппорты упорно слали в лес. На где-то 5 хостингах imap не поставили вообще, и пришлось оттуда уезжать.Казалось бы — мелочь. Но если у вас нет опыта, то мало того, что вы не знаете, какие модули php вам нужны, мало того, что почти никто из хостеров не публикует exact-список установленных модулей (чтобы можно было пробежаться по нему до переезда), так ещё и на том конце телефона козлятся. 2) Вторая (для меня — самая главная), хоть и не столь важная проблема для обывателей — https. https на shared-хостинге — это оксюморон. Хорошо, если он вообще просто выключен на сервере (и по 443-му порту ничего не доступно). Это правда счастье для тех, кому нужно, чтобы сайт работал только по http. Намного же чаще встречается такое, что по https://вашсайт открывается гребаная неведомая фигня и делать с этим ничего не будут. Конечно же, при этом там ругаются на невалидный сертификат все браузеры. В век дополнений, похожих на https-anywhere это действительно проблема.Причина-то очень простая — обычно на https:// хостеры вешают какую-нибудь панельку (тот же ispmanager так делает). Само собой, в конфигах вхостов про https ничего нет, но порт доступен — значит nginx тот-же будет показать default vhost. И хорошо, если там просто страница об ошибке — частенько там может оказаться и чей-то чужой сайт ;)Но даже если вы взяли отдельный IP (кстати не факт, что там тоже не будет неведомой хрени на https) и купили себе сертификат (и даже смогли его установить на хостинг, что даже для меня не очень тривиально в некоторых панелях — в конфиге nginx как-то сильно проще получается), то получить A-grade на sslrat-ингах вы вряд ли сможете — хостер делать ничего не будет, а дефолтовые конфиги дают только С. 3) Безопасность. Всё плохо, всё оооооочень плохо (с).Уязвимости не фиксятся не то, что месяцами — годами. В сети _до сих пор_ есть хостеры, уязвимые к heartbleed (кому интересно, их можно найти здесь — https://zmap.io/heartbleed/ , если приложить немножко усидчивости).Так как ребутить сервера shared-хостинга — это целая эпопея длиною в жизнь (тонны заявок, недовольных возгласов and etc), то и ядра там обрастают уязвимостями (в том числе и на тему получения рутового доступа через публично доступные эксплойты). А уж про libc я молчу.Сама модель «1 сервер, много пользователей, которые хотят навредить друг-другу» — достаточно сложна в администрировании (я её всегда стараюсь избегать — никто не готов оплачивать 10-20 часов работы по приведению такой помойки в порядок). Как следствие — у некоторых хостеров можно случайно подарить всем соседям свои файлы, выставив chmod 777 там, где не нужно (впрочем, тот же ispmanager от такой ситуации защищает из коробки и обойти эту «защиту» сможет только рут — чего не всегда скажешь о самописных панелях).У некоторых хостеров можно пойти и почитать что-нибудь в /var/log. Да, часть логов доступна только root (и группе adm). Но иногда находится что-нибудь повеселее — /var/log/mail.log, какой-нибудь. И да, в возможности чтения почтового лога всех пользователей саппорт того хостинга проблемы не видел =)Ещё в почти всех дистрах пользователь может посмотреть список пакетов. Тоже мало веселого. Ну или вот команда last интересная — её могут запустить пользователи, а она позволяет посмотреть список ip-адресов с привязкой к дате-времени логина по ssh и имени пользователя.Ну а уж если ваш сайт работает под пользователем www-data, то файлы сайта проще сразу положить на сервере отдельным архивчиком и выложить ссылку на этот архив на морде сайта. php-шеллы никто не отменял.Конечно, есть хостеры, которые засовывают каждого пользователя в отдельный контейнер/чрут/whatever, там с безопасностью получше. Но и цена там кусается, обычно. И проблем с обновлением софта никто не отменяет =) 4) Лимиты.У многих хостеров есть огромные развесистые лимиты (не всегда описанные в условиях тарифа, а только где-нибудь в оферте, которую никто никогда не читиает). Лимиты на количество mysql-запросов, лимиты на количество запросов к диску, лимиты на количество посетителей, на количество одновременно открытых соединений, на RAM, на процессор, на количество внешних запросов, на количество принятых/отправленных писем… Да черт возьми, на всё они там могут быть.И если с VPS бывает такая же хрень (привет, openvz), то там мы хотя бы можем примерно оценивать использование этих лимитов (да и подсчет там не такой дорогой получается).А теперь представьте — каждый mysql запрос должен быть куда-то залоггирован и по всем этим миллионам запросов в час нужно уметь строить какую-то статистику. Мхм. Само ведение подобного рода статистики жрет приличное количество ресурсов.Ах да — нам не всегда дают посмотреть на то, насколько мы используем эти ресурсы. О графиках вообще приходится только мечтать. Обычно, о «закончившихся лимитах» узнают тогда, когда сайт упал, а саппорт (спустя несколько часов ковыряния в этой своей непонятной системе лимитов) наконец-то сообщил нам, что мы сделали курлом за сутки не 100 запросов, а 101 и до 0:00 следующего дня сайт отключен =) 5) О том, когда сайт отключают.Я ни разу не видел, чтобы сайт отключали корректно. Видел редирект на сайт хостера (на страницу о том, что нужно заплатить денег), видел открывающуюся 404-ку хостера, видел наглецов, которые просто показывали сайт хостинга на отключенном за неуплату домене, видел 200ю страницу с текстом о необходимости оплаты.Но ни разу не видел 503-й страницы с указанием причины отключения и хоть какой-нибудь датой окончания даунтайма (например, текущее время + неделя). Такое ощущение, что ни один из хостеров не может прочитать статью Как справляться с запланированной недоступностью веб-сайтаНу а последствиях вы уже подумайте сами. Забыли оплатить хостинг, промучались неделю с их биллингом — а сайта нет в поисковых базах. Или, что ещё веселее, он склеился с сайтом хостера. Хехе. 6) Страницы об ошибках от хостера.Да, вы заливаете свой сайт, рисуете красивую 404-ку, заливаете её… И видите вместо 404-ки что-то в духе «Хостинг ГовноХост приветствует вас, такой страницы нет, но вы можете написать нам письмо». А ещё она может быть с 200-м кодом ответа, что совсем феерично.Да, скорее всего её можно поменять, да, скорее всего быстро, да только кто ж такие вещи проверяет, кроме дураков, вроде меня?7) Чисто российская фишка — РосКомНадзор.Да да, у нас в стране есть эта адская штука, а ещё есть приличное количество провайдеров, которые всё ещё не смогли завернуть трафик для IP-адресов с заблокированными сайтами на отдельный фильтрующий squid.В итоге, ваш сайт (про… ммм… котиков) показывает заглушку у трети населения РФ со словами о том, что на вашем сайте продавались наркотики. Ля-ля-ля.(забыл уточнить — сайт, который продавал наркотики, IP уже сменил и открывается у той самой трети населения — у остальных двух он зафильтрован по домену).Ну и да, ещё суд может постановить, что заблокировать нужно именно конкретный IP-адрес, тогда без переезда точно не обойтись. Если заблокировали домен соседа — то сколько-то времени у вас будет показываться заглушка, а потом пройдет. 8) И ещё одно следствие одного ip на всех — вас могут забанить не только в росцензурнадзоре.Отвалился однажды у человека сайт. Попросил меня разобраться, благо сайт был знакомым (и я им пользовался). Вспоминаю, что там было, припомнился апплет с курсами рубля от ЦБ РФ. При том рисовался он в коде сайта синхронно, с кешом на сутки. Но вот если кеш протухал, то там делался синхронный http-запрос в сторону серверов ЦБ.Тыкаемся курлом в ЦБ — курл через 180 секунд задумчиво говорит нам, что connection timeout. Хрена же себе, думаем мы. Заворачиваем запросы через проксю, всё работает, идём разбираться с хостером. Хостер дотумкался запустить tcpdump, в котором увидел примерно 2 запроса в секунду в сторону ЦБ. Да-да, по соседству жил сайт с курсами, достаточно популярный, но без кешей. И ЦБ у себя сделал -j DROP.(само собой, вся конкретика в этой истории заменена на выдуманную, и там вообще было не про ЦБ). 9) Ваша база почти ничем не защищена.На нормально настроенной VPS mysql слушает только порты на локалхосте. А заодно там выданы гранты только на то, что пользователь может зайти только с локалхоста. И рут может зайти только с локалхоста.То бишь, чтобы люди могли поделать запросы в вашу базу, им нужно попасть на ваш сервер (залить шелл, найти уязвимость в коде сайта, нужное подчеркнуть), помимо того, что спереть логин с паролем.На шареде у вас есть множество добрых соседей, которым уже залили шелл, из которого они могут пойти в вашу базу.Ещё есть популярная схема, когда mysql-сервер стоит в сети хостера на отдельной машине. Там иногда, конечно, выдают правильные гранты на правильные хосты (но тогда есть добрые соседи с залитым шеллом), но в особенно упоротых случаях гранты выдаются на все хосты и в базу потом можно ходить с любого IP. 10) Во время ddos-а вас с куда большей вероятностью просто выключат.Да-да, самым простым способом для хостера отбиться от ddos-а — просто отключить ваш сайт. Ведь есть добрые соседи, которые заплатили деньги и они страдать не должны.Ну то есть сделать map в nginx и банить ддосящих в нём и только для вашего сайта — это архисложно (не говоря уж о том, чтобы банить просто адреса в fw — ведь тогда ддосеры не смогут зайти на другие сайты нашего хостинга!). А просто выключить — дешево.И да — для некоторых хостеров ддос это 20 запросов в секунду. Ну или чуть больше.А ещё, если у вас стоит лимит на одновременное количество подключений, то уронить весь сайт может случайно чихнувший на ваш сайт поисковый робот.Нет, конечно VDS-ки тоже будут падать под досом, но хостерам на вас будет начхать до тех пор, пока ему аплинк не забьют. Так что от школьников можно будет отбиваться своими силами. 11) Вы намного больше страдаете от действий соседей.Если хостер всё же добрый и лимиты не настроил, то один бедный сайт может уронить всю железку. Ну или кто-то специально так сделает — написать скрипт, который забьёт IO SATA-сервера — дело 10 минут копания в гугле.Можно забить память, можно забить сеть исходящими запросами, можно забить диски по IO, можно забить диски по inodes, можно засрать CPU, можно… да много чего можно, если лимиты конкретно на это забыты. 12) Версии PHP/Python/whatever.На примере php — у большинства хостеров на сервере стоит ровно одна версия php, которую на этом сервере обновлять никогда не будут (а если будут — то это ещё хуже, кхе).У более продвинутых хостеров есть возможность выбрать версию, но вот работать она будет в каком-нибудь режиме CGI и адово тормозить (ну и напоследок там отломается кеширование через акселераторы).В итоге, хочется новую версию — ищем нового хостера (или переезжаем на новый сервер хостера, что в принципе равноценно, разве что искать не нужно будет). 13) низкий аптаймДа, хорошо настроенная VPS у хорошего хостера будет работать стабильнее любого shared-хостинга. А ещё она будет уходить на обслуживание тогда, когда вам это нужно, за редким исключением (вроде «ой блин, не тот шнурок выдернули»).Шареды страдают от досов (кому ваш сайт нужен? а если нужен — то почему вы всё ещё не в soyoustart на физической железке?), от ошибок в конфигурации (поставили точку с запятой, порестартили nginx, не посмотрели выхлоп), ребутов в дневное время ну и прочего. 14) О бэкапах нужно думать самому.Все хостеры делают бэкапы. Вот только не факт, что вы ими сможете воспользоваться, не факт, что в них будут актуальные данные, не факт, что хостер сам не восстановит сайт из бэкапа тогда, когда вам не нужно, не факт… В общем, надеяться на бэкапы хостера нельзя. Ни в коем случае.В конце концов, «Дело в том, что у нас было настроено автоматическое сохранение копий баз данных на другой сервер. Но этот сервер тоже располагался в сгоревшем Датацентре Hosting.ua.» (с)15) если вы поняли большинство слов в этой статье — то дорого.Хороший shared стоит 400-500 рублей (ну то бишь $10). Он будет избавлен от хотя бы половины из описанного выше. Там иногда будет отвечать саппорт. Ещё он будет на SSD, скорее всего, что тоже сильно помогает.Но за $10 можно взять виртуальную машину в… эээ… наверное уже двух десятках компаний с гигабайтом памяти, настроить её и жить-радоваться.
debian.pro
Облачный хостинг – что это и какие его преимущества
Облачный хостинг, как и любые другие облачные технологии, все больше обращают на себя внимание в последнее время. Однако, подробных обзоров новой услуги не так уже и много. Поэтому в этой статье разберем:
- облачный хостинг – что это и какие его преимущества;
- какие преимущества перед другими видами – shared-хостингом, VPS и Dedicated;
- какое отличие между публичным и личным облачным хостингом.
Облачные технологии – это одновременное использование ресурсов нескольких серверов.Главная особенность облачного хостинга – это возможность покупки ресурсов по потребностям и оплата за услуги в зависимости от нагрузки на сервер.При заказе облачного хостинга, нужно лишь выбрать какой размер дискового пространства вам понадобится для сайта. А оплата хостинга будет зависеть от того, сколько процессорного времени было затрачено на работу с вашими данными. Соответственно, чем больше будет расти посещаемость сайтов, тем больше будет использовано ресурсов серверов. Хотя и не все провайдеры используют данную схему оплаты услуг, первыми ее ввели Clodo, Selectel и Scalaxy.Любые другие параметры, которые можно встретить при заказе обычного виртуального хостинга, как например, пропускная способность в месяц (трафик), количество возможных доменов, суб-доменов, сайтов, баз данных, в облачном хостинге нету. Все это предоставляется без ограничений.
Основные преимущества облачного хостинга
- Доступность – ваши сайты будут доступные 24 часа 7 дней в неделю. Хостинг не размещён на одном сервере, а использует ресурсы целой сети серверов и такая сеть может объединять более 100 единиц. Для оптимальной работы всех сайтов в такой сети используется распределение нагрузки (балансер нагрузки) и разделение дискового пространства.
- Гибкость – для облачного хостинга можно подобрать оптимальную конфигурацию ресурсов под потребности определенного сайт.
- Надежность – благодаря использованию сети серверов ваши сайты будут работать наиболее стабильно. Один или несколько серверов будет предоставлять вычислительные ресурсы, еще сервера будут делать бекап данных, а другие, в случае надобности, будут восстанавливать эти резервные копии. Данная схема работы просто исключает заторможенность или недоступность сайта.
- Оплата – вы платите только за те ресурсы, которые вам необходимы, если их окажется мало, вы всегда можете улучшить конфигурацию облачного хостинга или наоборот. Так что нет необходимости покупать ресурсы с «запасом».
- Никогда не получите письма от владельцев серверов о «превышении нагрузки» и просьбой перейти на более дорогой тарифный план или купить ВДС.
Сравнение преимуществ
При обычном заказе хостинга – вы покупаете сервер, или выделенное дисковое пространство на выделенном сервере. И если вы делите один сервер с множеством других пользователей, то это негативно сказывается на работе вашего сайта. Облачный VDS хостинг позволяет избежать этого за счет равномерного распределения нагрузки на всех серверах. Иногда облачный (cloud) хостинг называют «кластерным хостингом».
Shared хостинг или Облачный хостинг
Shared-хостинг – это самый доступный и дешевый вариант для размещения сайта. Возможности данного хостинга минимальный, по сравнению с VPS или дедиками.Плюсом виртуального хостинга является .Минусом – ухудшение работы сайта при высокой нагрузке. А все от того, что по соседству с вашим сайтом может находится сотня таких же проектов и сервер просто не выдержит даже среднего притока пользователей на нескольких проектов. Хотя виртуального хостинга может быть вполне достаточно для сайтов с небольшим трафиком.Облачный виртуальный хостинг за счет распределения вычислительных мощностей не имеет проблем с перегруженностью сервера. А если загруженность появляется, то часть операций обрабатывается менее перегруженными серверами.
VPS или Облачный хостинг
Виртуальный выделенный сервер (он же в английской аббревиатуре VPS) – это более мощная платформа для крупных проектов. Если кратко, то ВПС – это виртуальная среда с выделенным местом на диске, оперативной памятью, процессорной квотой и с любой операционной системой.На таком виртуальном сервере можно установить любое ПО и настраивать его под себя, при этом вам практически не мешают другие сайты размещенные на этом сервере. Кажется, что все идеально, но нагрузка на сервер меняется в зависимости от времени суток. Ночью и утром ВПС слабо загружен, а под вечер начинает перегружаться. И часто из-за таких нагрузок приходится заказывать больше ресурсов для поддержания вечернего трафика, хотя большую часть времени эти ресурсы простаивают.Облачные хостинги решают и эту проблему. Для него возможно устанавливать смену тарифного плана ручным или автоматическим режимом, а также устанавливать почасовую тарификацию услуг. Нет нагрузок – выбираете дешевый тарифный пакет, повалили посетители – берите хоть кластер из всех физических серверов.
Dedicated или Облачный хостинг
Dedicated – это заказ выделенного физического сервера. Самая лучший вариант для сайта, но с появлением облачного хостинга он ставит под вопрос необходимость покупки дедика. Купить выделенный сервер или может лучше заказать облачный ВПС и разогнать его до любых конфигураций, которые могут в разы превышать ресурсы одного дедика. При этом вы в любое время можете уменьшить их до минимальных в целях экономии средств.
Провайдеры
Перечислим наиболее популярных провайдеров, которые предоставляют облачный хостинг. Рейтинг или цену указывать нет смысла, так как данные устаревают буквально за месяц. Компании отличаются как ценой, так и разными конфигурациями серверов. Например, облачный хостинг, Windows в качестве операционной системы может предложить scalaxy.ru. Остальные же больше ориентируются на Linux. О хостингах 1с поговорим в другой теме.Где именно размещены серверы, Россия, Украина, США, Германия, уточняйте в саппорте. Многие вебмастеры считают, что размещение сервера влияет на геотаргетинг и они скорее всего правы, даже в документации Google указано, что страна сервера влияет на привязку к региону. Недорогой облачный хостинг можно найти за 100 руб./месяц.
Публичный и личный сервер
Облачный хостинг можно разделить на две категории: личный и публичный сервер. Хотя они и похожи в некоторых аспектах, различия все же существуют.Публичный облачный хостинг. Основное преимущество – это конечно же цена, она значительно ниже личного клауд хостинга. Однако, данные с такого хостинга могут быть украдены хакерами или скачены с помощью вредоносных программ. Кроме того, будет недоступен ряд опций и вы не сможете под себя настроить хостинг. Бесплатный облачный хостинг чаще всего публичный.Личный облачный хостинг. Цена на него выше, чем за публичный, но он лучше защищен. Личные облачные хостинги дают возможность самостоятельно настроить структуру платформы, и дает бизнесу лучший контроль над размещенными данными и юзерами. Для бизнеса выбирают именно этот вид хостинга, дабы получить защищенность данных и возможность настроить платформу под свои нужды.
hardwareguide.ru
