Вкладывать средства в отказоустойчивость физического сервера, на котором развернута вся серверная инфраструктура, или купить несколько серверов?

Вкладывать средства в отказоустойчивость физического сервера,
на котором развернута вся серверная инфраструктура,
или купить несколько серверов?

На вопрос «СА» отвечают посетители форума сайта журнала

Виртуализация смягчает требования к надежности

Сейчас создано огромное превосходство возможностей оборудования по сравнению с требованиями ПО. И вполне уже можно запускать в виртуальном окружении каждую рабочую станцию. Вот прямо так: сначала стартует хостовая ОС, потом из набора профилей стартует нужная система по запросу в виртуальном окружении. Профили (читай: виртуальные машины) могут быть как локальными, так и удаленными, как остановленными, так и просто замороженными. Короче, виртуализация это вообще не проблема. И уж тем более не проблема критической надежности. Если виртуальная машина или её хостовая ОС грохнулась, то всегда есть снапшот, и на любой хостовой машине всегда есть набор совместимых (потому что виртуальные)) девайсов для оживления данного снапшота в готовую для эксплуатации систему. Главная мысль: виртуализация не ужесточает требования к надежности, а напротив – смягчает их!

Лучше не рисковать

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

Виртуализация, безусловно, стоит денег. Но тут вопрос уже к заказчику сервисов, которые предоставляет ему ИТ: нужно ли ему, чтобы все работало или можно подождать, пока один из сервисов упадет. Сколько можно подождать? Если срок восстановления сервиса, например, составляет сутки, то и пусть все работает как есть. Виртуализировать все нереально, да и не нужно.

Виртуализация задала новый вектор развития заводу

Я работаю на заводе, где использовался Visual Foxpro для DOS, и еще несколько скомпилированных программ на фортране под dos (для расчета зарплаты). У нас был устаревший (по нынешним меркам парк машин), также использовались сервера с 486-процессорами. Со временем они износились, стали нестабильно работать.

Тогда было принято стратегическое решение, которое в будущем задало вектор развития заводу. Мы купили мощный сервер с двумя процессорами, и установили там VMware workstation. После чего для каждого из старых серверов была сделана виртуальная машина под управлением Windows 2003 Server, в которой уже использовался dosbox для наших приложений.

Cейчас у нас все просто замечательно работает. Пользователь удаленным столом заходит на виртуализированную windows машину, в окошке запускает dosbox и работает! Налицо экономия. Даже одной электроэнергии в квартал мы сэкономили на 12 тысяч рублей. А это согласитесь немало.

Геннадий Болтов

Не надо складывать яйца в одну корзину

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

Андрей Луконькин

А почему и нет?

Представим, что у нас два железных сервера и два приложения. По традиционной схеме мы раскладываем по приложению на сервер. В случае выхода из строя одного из них поднимаем на втором упавшее приложение из бэкапа или ещё как-то. А теперь представим, что у нас два железных сервера и две виртуальные машины, внутри которых живут наши два приложения. Если один железный сервер умер, упавшая виртуальная машина будет перенесена на живой сервер. Выгода нетрадиционного подхода – в скорости переноса виртуальной машины: хороший виртуальный софт делает это за секунды или минуты.

У нее много задач, но только не экономия

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

• уменьшать время простоев (при кластерной схеме);
• уменьшать время восстановления после отказов;
• делать доступной работу тонких и удаленных клиентов (причем платформо независимую);
• облегчать управление и администрирование всем программно-аппаратным хозяйством;
• для разработчиков – это легкий способ создать большое количество разнообразных сред для тестирования.

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