Лекция
Привет, Вы узнаете о том , что такое инфраструктура веб сайта, Разберем основные их виды и особенности использования. Еще будет много подробных примеров и описаний. Для того чтобы лучше понимать что такое инфраструктура веб сайта, хостинг, виртуальный хостинг , настоятельно рекомендую прочитать все из категории Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы.
хостинг (англ. hosting) – это услуга предоставления ресурсов и инфраструктуры для размещения веб-сайтов, приложений или других онлайн-сервисов. Хостинг-провайдеры (или хостеры) предоставляют аренду серверов или виртуальных серверов, на которых можно разместить свой веб-сайт или приложение. Хостинг позволяет веб-сайтам и приложениям быть доступными в Интернете 24/7 без необходимости в собственной инфраструктуре и поддержке. Клиенты хостинг-провайдеров могут выбирать различные типы хостинга в зависимости от своих потребностей, такие как общий хостинг, виртуальный частный сервер (VPS), выделенный сервер, облачный хостинг и другие, подробнее ниже.
Основные компоненты хостинга включают:
Серверы: Хостинг-провайдеры обеспечивают серверы, которые предоставляют вычислительные ресурсы, хранение данных и сетевое подключение для вашего веб-сайта или приложения. Серверы могут быть физическими машинами или виртуальными машинами, в зависимости от типа хостинга.
Хранилище данных: Хостинг-провайдеры предоставляют место для хранения файлов вашего веб-сайта, включая HTML, CSS, изображения, видео, базы данных и другие ресурсы. Это может быть представлено в виде дискового пространства на сервере или через облачные хранилища данных.
Сетевое подключение: Хостинг-провайдеры обеспечивают сетевое подключение для вашего веб-сайта или приложения, чтобы они были доступны в Интернете. Это включает широкополосный доступ к Интернету, сетевую инфраструктуру и обеспечение безопасности.
Управление сервером: Хостинг-провайдеры предоставляют инструменты и интерфейсы для управления вашим веб-сайтом или приложением на сервере. Это может включать панель управления, FTP-доступ, SSH-доступ и другие инструменты для управления файлами, базами данных, настройками сервера и т. д.
Техническая поддержка: Хостинг-провайдеры предоставляют техническую поддержку для помощи в решении проблем, настройке сервера или решении вопросов безопасности. Это может включать электронную почту, онлайн-чаты, телефонные звонки или тикет-системы поддержки.
Итак, что же такое виртуальный Apache хостинг? Это один большой сервер, на котором достаточно высокая плотность «населения», что делает его очень дешевым, доступным и массовым. Но в связи с этим существует ряд проблем, которые подстерегают клиента, многие из которых нам удалось решить, внедрив хостинг четвертого поколения.
Вы заранее знаете, что у вас будет система авторизации и что понадобится хранить информацию о пользователях, поэтому нужна база данных. Из-за ограниченного бюджета разместим ее на нашем единственном сервере. В конечном итоге получаем такую инфраструктуру:
Рис. 1
Пока этого достаточно. На самом деле такая система может проработать довольно долго. Сервис маленький, менее 10 посещений в день. Возможно, и маленького инстанса было достаточно, но мы с оптимизмом смотрим на рост компании .
Ценность бизнеса — в базе данных, поэтому она очень важна. Нужно убедиться, что если сервер выходит из строя, вы не потеряете данные. Вероятно, следует убедиться, что содержимое базы не хранится на временном диске. Ведь если инстанс удалят, вы потеряете свои данные. Это очень страшная мысль.
Также следует убедиться, что у вас есть резервные копии на внешнем хранилище. S3 кажется хорошим местом для них, и относительно недорогим, поэтому давайте также настроим и это. И нужно обязательно проверить, что бэкап работает, периодически восстанавливая резервную копию.
Теперь система выглядит примерно так:
Рис. 2
повысили надежность базы данных, и пришло время подготовиться к «оверлоад», прогнав на сервере нагрузочный тест. Все идет вроде нормально, пока не появляются ошибки 500, а затем поток ошибок 404, поэтому вы изучаете, что произошло.
Оказывается, вы понятия не имеете, что произошло, потому что писали логи в консоль и не направляли выдачу в файл. Вы также видите, что процесс не работает, так что можно с большой вероятностью предположить, что именно поэтому появляются ошибки 404. Накатывает волна облегчения, что вы грамотно запустили локальный нагрузочный тест, а не вызвали реальный хабраэффект в качестве тестовой нагрузки.
Вы исправляете проблему с автоматическим перезапуском, создав службу systemd, запускаете веб-сервер, который одновременно решает проблему с записью логов. Затем запускаете еще один нагрузочный тест для проверки.
И опять видим ошибки 500 (к счастью, без 404). Вы проверяете логи. Обнаруживается, что пул подключений к базе данных заполнен, потому что было установлено маленькое ограничение в 10 подключений. Обновляете ограничение, перезапускаете БД и снова запускаете нагрузочный тест.
Ваш сервис мгновенно становится хитом. Вы попали на главную страницу и получаете 7000 просмотров за первые 30 минут — и видите комментарии. Что там пишут?
У меня ошибка 404, поэтому пришлось открыть кэшированную версию страницы. Вот ссылка, если кому надо: …
…
Ничего не открывается. Кроме того, у меня отключен Javascript. Почему люди считают, что я хочу грузить их Javascript на 2 МБ…
…
Загрузка домашней страницы занимает 4 секунды. Traceroute из Австралии показывает, что сервер размещен где-то в Техасе. Кроме того, почему первая страница загружает 2 мегабайта Javascript?
В безумной спешке вы настраиваете Nginx в качестве обратного прокси-сервера для своего приложения и настраиваете там статическую страницу 404. Вы также изменяете процедуру деплоя, чтобы отправлять статические файлы в S3: это необходимо для работы CloudFront CDN, чтобы сократить время загрузки в Австралии.
Рис. 3
Вы решили самую насущную проблему, идете на сервер и проверяете логи. Об этом говорит сайт https://intellect.icu . Ваше соединение SSH необычно лагает. После некоторого изучения вы видите, что файлы логов полностью израсходовали дисковое пространство, что привело к сбою процесса и предотвращению его повторного запуска. Создаете диск гораздо большего размера и монтируете туда логи. Настраиваете logrotate, чтобы файлы логов больше не разрастались до таких размеров.
Проходят месяцы. Аудитория растет. Сайт начинает тормозить. Вы заметили в мониторинге CloudWatch, что это происходит только между 00:00 и 12:00 UTC. Из-за одинакового времени начала и окончания лагов вы догадываетесь, что это связано с запланированной задачей на сервере. Проверяете crontab и понимаете, что одно задание запланировано на полночь: резервное копирование. Конечно, резервное копирование занимает Х часов и приводит к перегрузке базы данных, вызывая значительное замедление работы сайта.
Вы читали об этом раньше — и решаете запускать резервные копии в подчиненной БД (slave). Затем вспоминаете: у вас же нет подчиненной базы данных, поэтому ее нужно создать. Не имеет большого смысла запускать базу данных slave на том же сервере, поэтому вы решаете расширяться. Создаете два новых сервера: один для базы данных master и один для базы данных slave. Изменяете резервное копирование для работы с подчиненной БД.
Рис. 4
Некоторое время все идет гладко. Проходят месяцы. Вы нанимаете разработчиков. Один из новичков вносит баг, который валит производственный сервер. Разработчик обвиняет среду разработки, которая отличается от продакшна. В его словах есть доля правды. Поскольку вы разумный человек с хорошим характером, то воспринимаете это событие как урок.
Пришло время создать дополнительные окружения: промежуточное (staging), QA и продакшн. К счастью, вы с первого дня автоматизировали создание инфраструктуры, так что все проходит гладко и просто. У вас также с первого дня налажены хорошие практики непрерывной доставки, поэтому вы легко собираете конвейер из новых веток.
Отдел маркетинга настаивает на выпуске версии 2.0. Вы не совсем понимаете, что значит 2.0, но соглашаетесь. Пора готовиться к очередному всплеску трафика. Вы уже близки к пику на текущем сервере, так что пришло время для балансировки нагрузки. Amazon ELB легко делает это. Примерно в это время вы замечаете, что многоуровневые диаграммы в этой статье должны показывать слои сверху вниз, а не слева направо.
Рис. 5
Уверенный в том, что вы справитесь с нагрузкой , делаете рекламу сайту. О чудо, он выдерживает трафик. Большой успех!
Все вроде шло хорошо, пока вы не пошли проверять логи. На проверку 12 серверов ушел час (по четыре сервера в каждом окружении). Настоящая нервотрепка. К счастью, денег хватает на покупку стека ELK (ElasticSearch, LogStash, Kibana). Вы развертываете его и направляете туда серверы со всех окружений.
Рис. 6
Вы замечаете похожие подозрительные записи в логах серверов БД и удивляетесь, как они вообще подключились к интернету. Пришло время внедрять публичные и частные подсети.
Рис. 7
Выделяют следующие типы хостингов:
git push
. Кроме цены важно учитывать используемые технологии и подходы. PaaS обладает наибольшим числом ограничений по тому, что и как можно делать, но в обмен вы получаете не просто автоматизированный хостинг, но и платформу, которая автоматически «скейлится» (масштабируется) под нагрузку.
Веб-серверы:
Серверы хранения данных:
Конфигурационная база данных и управляющий модуль:
В классическом хостинге сайты клиентов на одном сервере не изолированы друг от друга, что дает бреши в безопасности при наличии соседа — злоумышленника, либо если сайт соседа проломан. Так же если на соседа идет DDoS атака, или просто высокая нагрузка — страдают все.
В своем старом хостинге мы решили проблему повышенного количества запросов ( которая зачастую встает не менее остро, чем DDoS атаки. да-да привет хабраэффект) установкой на каждую группу веб серверов фронтенда с Nginx, который работает фильтрующим прокси, тем самым мы можем балансировать нагрузку на сайты в пределах одного сервера. Но проблема с изоляцией осталась, все сайты работают с php как mod apache, и все равно живут в едином общем пространстве. Это грустно.
Что по этой части в нашем новом хостинге? Во-первых, в нем иная архитектура, представляющая из себя кластер, где нагрузка равномерно распределяется между веб-серверами. У нас используется php через FastCGI, что дает нам разные UID на все вебспейсы, это уже хорошо и безопасно. А так же очень круто, что каждый вебспейс — это LVE(Light Virtual Environment), маленькая виртуальная машинка, где все скрипты работают изолированно от других вебспейсов в своем виртуальном пространстве, на которое выделены определенные ресурсы памяти и процессорного времени. Все это — благодаря дистрибутиву Cloud Linux:
Ну и плюс ко всему, так же можно использовать Nginx. Так что с безопасностью в новом хостинге замечательно.
На стабильность хостинга влияют проблемы, описанные в предыдущем пункте. Все пользователи варятся в одном котле и используют общие ресурсы. А еще стабильность под угрозу ставит то, что любым системам свойственно ломаться, потому из-за проблем с железом или софтом(упал демон апача например) без хостинга остаются все жители проблемного сервера, это ужасно, правда?
С нашим старым хостингом все то же самое — общие ресурсы, общая память и процессорное время, такова плата за архитектуру – как ни крути. Но проблему с железом мы побороли тем, что все наши сервера виртуализированны, а именно находятся в контейнерах Parallels Virtuozzo. Это здорово, потому что если сервер требуется масштабировать и дать ему больше ресурсов, либо провести профилактику по железу — мы просто перевозим контейнер на более мощный сервер без простоя сайтов. Если же внутри контейнера случилась проблема с софтом (ну с кем не бывает?) все сидят без хостинга пока технический отдел исправляет ошибку, такие вещи если и случаются, то всего на несколько минут, но все равно неприятно для заказчиков. У них бизнес, клиенты, посетители, которые расстроятся, если их сайт ляжет пусть даже на несколько минут.
Новый хостинг тут дает фору всем. LVE, про которые было сказано в предыдущем пункте дают четко лимитированные ресурсы для каждого вебспейса, то что хотел клиент — то он получит, и не сможет притеснить соседей по серверу ни по процессору, ни по памяти – такой подход уже ближе к VPS, нежели к виртуальному хостингу. А еще благодаря кластерной архитектуре, если вылетает один из фронтендов (горизонтально их можно масштабировать сколь угодно), то все запросы распределятся по другим фронтендам. То есть даже если вылетит железо или софт на одном из веб-серверов — балансер сию секунду вычеркнет проблемный сервер из кластера и перераспределит нагрузку между оставшимися серверами, и клиент никогда не узнает, что на одном из серверов случилась беда. Такое решение за счет своей полной автономности и автоматизации делает новый хостинг дешевле для нас и как следствие для Вас. В результате мы больше времени тратим на новые интересные вещи и идеи.
Плюсы :
«Честное» разделение ресурсов, каждому сайту назначены ресурсы, которые он не может превысить
Безопасность, все сайты работают в отдельных LVE и изолированы
Отказоустойчивость и стабильность, кластерная архитектура.
Масштабируемость, управляющая база «на ходу» может менять разрешенные вашему сайту ресурсы
Скорость, Apache работает в режиме MPM Worker.
Минусы :
Могут возникнуть проблемы с FastCGI режимом PHPдля сайтов, написанных в начале прошлого десятилетия. Впрочем, практически все современные движки и CMS поддерживают его нативно и безболезненно.
За счет изолированности сайтов, ваши права на ресурсы никто не стеснит, но с другой стороны ваш сайт не сможет получить ресурсов больше, чем ему назначено.
Рис пример Архитектура серверов крупной системы
Исследование, описанное в статье про инфраструктура веб сайта, подчеркивает ее значимость в современном мире. Надеюсь, что теперь ты понял что такое инфраструктура веб сайта, хостинг, виртуальный хостинг и для чего все это нужно, а если не понял, или есть замечания, то не стесняйся, пиши или спрашивай в комментариях, с удовольствием отвечу. Для того чтобы глубже понять настоятельно рекомендую изучить всю информацию из категории Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы
Комментарии
Оставить комментарий
Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы
Термины: Высоконагруженные проекты.Паралельные вычисления. Суперкомпьютеры. Распределенные системы