ЦОД
Фабрика ЦОД как фактор производительности приложений
При каких условиях сетевая инфраструктура способна оказывать влияние на производительность приложений? В какой степени? От каких факторов это зависит? Что можно предпринять для того, чтобы сетевая инфраструктура не «тормозила» приложения? Озвученные вопросы нашли отражение в одной из тем нашего семинара. Файл презентации доступен по ссылке ниже.
ЦОД. Как уменьшить область распространения атаки?
Почти все ЦОД в тех технических решениях, с которыми мы встречались, имеют одну общую черту – периметр, образованный из средств защиты информации (как правило, это FW, IPS, AV, WAF, и, возможно, Sandbox). По аналогии с драже M&M’s такой ЦОД снаружи «твердый», а внутри периметра «мягкий». Чем это оборачивается для предприятия? На практике оказывается, что периметр не такой и «твердый», и злоумышленник всегда находит лазейку, чтобы его пройти. И когда злоумышленник оказывается внутри периметра ЦОД, шансы предприятия обнаружить или хоть как-то сдержать атаку близки к нулю. О некоторых подходах к решению этой проблемы пойдет речь ниже.
О подключении серверов к фабрике
Задачам, встречающимся на границе двух различных систем, зачастую не уделяют должного внимания. Взять, к примеру, центр обработки данных, с серверами и фабрикой. Как правило, объект “сервер” работает под управлением среды виртуализации. И, как правило, упор при этом делается на виртуализацию аппаратных ресурсов (процессор, память, диск). С другой стороны, есть объект “фабрика”, функция которого – предоставление транспорта для трафика серверов.
Мобильность виртуальных машин. Действительно ли нужна L2 связность?
Виртуализация вычислительных систем в ЦОД позволила сделать приложения мобильными, в том числе позволила осуществлять их горячую миграцию. Этот инструмент может оказаться полезным в сценарии, когда необходимо обслужить сервер, предварительно перенеся с него нагрузку на соседний. На мой взгляд, в остальных сценариях проще сделать холодный перезапуск приложения В особенности, это касается ситуаций, когда новое место запуска приложения на другой площадке…
ЦОД. Конвергентные системы хранения данных
В любой организации, желающей автоматизировать свои процессы с помощью IT, задействовано множество прикладных систем. Каждая из этих систем, как правило, работает с определенным набором данных. В процессе своего развития отрасль пришла к состоянию, когда для хранения разрозненных наборов данных используют одну или несколько специализированных систем хранения. Такая консолидация ресурсов, безусловно, положительно сказывается на удобстве администрирования и доступности данных. Отдельной задачей…
Решение одной задачи балансировки запросов к веб-приложениям
Как-то раз к нам обратилась одна компания с просьбой предложить решение по балансировке запросов к корпоративному веб-приложению. Проблема была в том, что сервер приложения начинал «тормозить» (читайте, не мог обеспечить приемлемое время отклика) в моменты, когда на приложение «наседало» много пользователей. И поскольку карта вертикального масштабирования сервера приложения уже была разыграна, в компании было принято решение запустить несколько экземпляров сервера приложения и распределить запросы пользователей между ними (см. рисунок ниже). Таким образом, в конечном итоге было запущено 3 сервера приложения, а на рабочем столе пользователя появились 3 ярлыка: каждый ярлык запускал сеанс пользователя на соответствующем сервере приложения.
Обработка нештатных ситуаций в MLAG
В работе любой системы, как правило, можно выделить как минимум два режима функционирования — штатный и нештатный. Причем, как вы понимаете, эти режимы могут отличаться друг от друга по поведению весьма существенно. И хотелось бы верить в то, что при создании любых систем этот факт принимается во внимание. А администратор не начинает в панике бегать по потолку, когда какой-то компонент…