LINUX.ORG.RU
ФорумAdmin

Правильная организация веб-серверов

 


1

2

Здрасти

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

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

http://storage1.static.itmages.com/i/16/0807/h_1470549199_4051626_a6c61a4706.png

Здесь 1 - Load Balancer, DNS Server, Firewall. У него единственного есть публичный айпи адрес. 2 - Собственно, сами веб-сервера. Точнее, та их часть, которая отвечает за обработку и выдачу страниц. 3 - Сервер базы данных 4 - Файловый сервер (3/4 возможно размещать на одной машине) . - Для отказоусточивости.

Между 1, 2 и 3 существует связь только по локальным IP-адресам. Напрямую достучаться до этих серверов невозможно. При этом, над безопасностью 1 нужно поработать как следует. 2 - тупые веб сервера, которые можно клонировать, и в случае необходимости(упали какие-то 2 или нехватает производительности) просто добавлять еще одни. В данном примере была указана минимальная схема, в которой есть отказоустойчивость во всех пунктах, но если наших посетителей будет больше, нам просто надо будет увеличить количество «2» (если конечно вырастут они не в 10ки раз, тогда уже придется и «1» помощнее (или побольше в количестве), и 3/4 помощнее). 3/4 в количестве увеличивать нам ничего не даст, если конечно не сегментировать сами данные. То есть в дальнейшем можно привести к такому виду:

http://storage1.static.itmages.com/i/16/0807/h_1470549199_6904917_cdc9840ed2.png

Почему мы увеличиваем количество 2, а не производительность? Во первых, если у нас есть старенькие сервера/компы, можно запросто их задействовать в этом, и они будут давать небольшой прирост. Скажем, когда у нас нету денег на новое оборудование. Можно хоть на компах сотрудников поднять виртуалки, тупо забросив образы «2» (шутка, конечно, хотя..).

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

А также пара дополнительных вопросов: 1) Стоит ли реализовывать такую схему на VPS? Скажем, поднять на Амазоне такую вот схему. Амазон дает год бесплатного ЕС2 каждому, так что по идее можно зарегистрировать парочку пользователей и у каждого поднять нужную машину. Так, чтобы поиграться. Или это бред? 2) Какой софт вы юзаете в качестве Load Balancer, Firewall, Web-Server, Mail server, DNS server, Data Base server и т.д.?

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



Последнее исправление: Datt_ (всего исправлений: 2)

связь только по локальным IP-адресам. Напрямую достучаться до этих серверов невозможно

Вот это я понимаю, инновации !
Еслиб все так делали, то никого бы не покакали.
Осталась самая малость:

над безопасностью 1 нужно поработать как следует

З.Ы.: мимкрокодильный параноик рекомендует все сервера в отдельных vlan держать.

Deleted
()

ломать будут в первую очередь бд инъекциями (даже за большие коврижки этот г-код сложно убрать - это может доходить до 60% кода/софта), веб-сервер некорректными запросами и поиском «исполняемых дыр» с аплоадом

anonymous
()

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

* ТОРМОЗА! Даже если все сервера в локалке, и там низкий пинг, все равно будут сетевые задержки — если взять страницу с 50ю запросами, то можно смело накинуть +30ms. То же самое web-frontend --> web-backend, можно накинуть +5ms.

* Файловый сервер. Самым быстродейственным оказался NFS, но даже он адски тормозил на куче мелких файлов. Пришлось извращаться с костылями а-ля «разогревание дискового кэша», типа по крону читать tar-ом критичное по скорости отклика файло. В общем, тут +200ms можно смело накинуть.

* Репликация файлового сервера, сервера БД - она имеет тенденцию ломаться. Это добавляет сложности в обслуживании и квалификации тех персонала. Но не влияет на скорость, и то ладно.

* Изоляция. А много ли знаете провайдеров ВПС-ов, которые позволяют организовать свою локалку? я только на AWS и наверное Rackspace. Остальные да, предоставляют локалку, но она не полностью изолирована (digitalocean, linode).

ИТОГ. По прежнему самым простым и эффективным, а главное, быстрым будет обычный LAMP сервер, со всем фаршем в пределах одного сервера. Ну, максимум, можно кэш выставить вперед, по типу Cloudflare.

Bers666 ★★★★★
()
Ответ на: комментарий от Bers666

50 запросов к бэкэнду для одной страницы? Обычно на бэкэнд идёт один-два запроса, остальные обслуживаются фронтэндом

MrClon ★★★★★
()
Ответ на: комментарий от Bers666

Самым быстродейственным оказался NFS

как насчет ISCSi?

Репликация файлового сервера, сервера БД - она имеет тенденцию ломаться

и что использовалось? Galera/NDB?

snaf ★★★★★
()
Ответ на: комментарий от snaf

как насчет ISCSi?

Это ж для расшаривания блочного устройства, не? Так что не подходит, ведь нам надо идентичный контент на N бакенд-серверах, в режиме Read\Write. Наверное, ISCSI хорошо для доступа _одного_ сервера к _одному_ блочному устройству.

и что использовалось? Galera/NDB?

Банальный Mysql master + пару slave. И разделение R и RW запросов на уровне приложения. Но не суть. Попробуйте меня переспорить, что добавляя репликацию, мы добавляем риск ее иногда поломать кривым запросо и внезапно чинить, рвя волосы на голове.

Bers666 ★★★★★
()

А мне вот это понравилось.

«отказоустойчивость»

.....

у нас есть старенькие сервера/компы, можно запросто их задействовать в этом, и они будут давать небольшой прирост. Скажем, когда у нас нету денег на новое оборудование. Можно хоть на компах сотрудников поднять виртуалки, тупо забросив образы «2» (шутка, конечно, хотя..).

3/4 в количестве увеличивать нам ничего не даст

Выиграли аукцион и теперь не знаете что с этим делать?

anc ★★★★★
()
Ответ на: комментарий от Bers666

* ТОРМОЗА! Даже если все сервера в локалке, и там низкий пинг, все равно будут сетевые задержки — если взять страницу с 50ю запросами, то можно смело накинуть +30ms. То же самое web-frontend --> web-backend, можно накинуть +5ms.

30ms разве это «ТОРМОЗА!»?

* Файловый сервер. Самым быстродейственным оказался NFS, но даже он адски тормозил на куче мелких файлов. Пришлось извращаться с костылями а-ля «разогревание дискового кэша», типа по крону читать tar-ом критичное по скорости отклика файло. В общем, тут +200ms можно смело накинуть.

Вот я так иногда делаю, файло на другом сервере подключенным через nfs - только раздается оно с него (http://files.server.com) и тормозов нет. Минус только в том, что в приложении должно это учитываться.

pi11 ★★★★★
()
Последнее исправление: pi11 (всего исправлений: 1)
Ответ на: комментарий от pi11

30ms разве это «ТОРМОЗА!»?

Да это в лучшем случае. А в худшем - пропорционально кол-ву плагинов/свистелок прикрученных к сайту.

файло на другом сервере подключенным через nfs - только раздается оно с него (http://files.server.com) и тормозов нет.

Интересно. Ну это можно и на уровне web frontend делать, форвардить прямо на nginx который на NFS сервере, соответственно там такие же vhost-ы поднять. Да, это рулит для «статических файлов».

Но у меня проблема была в другом: сайт, чтоб выплюнуть ответ, должен был локально прочитать все свои темы/плагины/ядро wordpress, а это около 10к мелких файлов. Так что оно натыкалось на тормоза NFS.

Bers666 ★★★★★
()
Ответ на: комментарий от Bers666

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

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

anc ★★★★★
()
Ответ на: комментарий от Bers666

Но у меня проблема была в другом: сайт, чтоб выплюнуть ответ, должен был локально прочитать все свои темы/плагины/ядро wordpress, а это около 10к мелких файлов. Так что оно натыкалось на тормоза NFS.

У тебя исходники сайта хранятся на другом сервере? Но зачем?

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

Dmit3Y
()
Ответ на: комментарий от Dmit3Y

У тебя исходники сайта хранятся на другом сервере? Но зачем?

Эм? Вы прочли, о чем тред? Файло на NFS, backend- сервера (их несколько!) его монтируют. Что хранить локально?

на всякий случай уточню, что ответ это таки 1 (одно) тело ответа в ответ на запрос типа «GET /»

Bers666 ★★★★★
()
Ответ на: комментарий от anc

Мама дорогая, до чего же вэбмакаки дошли, а

ну а шо вы хотели, вон сколько разных плагинов для вордпресс, и все нужны))

Bers666 ★★★★★
()
Ответ на: комментарий от Bers666

Да, прочел.

Хранить локально весь сайт на wordpress, на каждом backend сервере.

Dmit3Y
()
Ответ на: комментарий от Bers666

мы добавляем риск ее иногда поломать кривым запросо

никогда с таким не встречался.

snaf ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.