pen_06
16 Сенября 2012 г.
На главную Карта сайта

Как на самом деле устроена наша инфраструктура.

Как вы знаете, у нас есть два бизнеса – оффлайновый бухгалтерский аутсорсер «Ассоциация Профессиональных Бухгалтеров» - http://new.apb-ul.ru/; и разработчик программного обеспечения ForestValley, с которым мы выходим в онлайн. Специфика бухгалтерии такова, что наши клиенты сильно зависят от бесперебойности нашей работы, а так же от секретности, поэтому у нас «всё секьюрно и трафик закриптован» (с). При этом всё дублировано и работает быстро. Для неспециалистов мы с Юрой Бушмелевым уже рассказывали об этом здесь и здесь. Сейчас я расскажу уже специалистам.

Вот как оно всё устроено.

cluster

Почти все программы у нас работают в своей виртуальной машине. В качестве гипервизоров мы используем XCP, раньше использовали бесплатную версию Citrix XenServer. Гипервизоров два, довольно слабые серверы, один старый Dual Xeon LGA771 3,2 GHz Quad core+12 GB FB-DIMM, другой посвежее Xeon X3440 LGA1156 2,4 GHz Quad core + 16 GB DDR-3. Стоят на них по одному диску, исключительно для загрузки гипервизора.

Вся информация у нас лежит на хранилищах данных, подключенных по iSCSI к гипервизорам. В качестве хранилищ - два древних сервера с Xeon 2,4GHz Socket604, в каждом по Adaptec 6805, по семь винтов SAS 2.0 1TB 2’5, собранных в массивы RAID6 (для надёжности). Хранилища соединены в кластер таким образом, что при выходе любого из них из строя работа не притормаживается ни на секунду. Они работают как зеркало. Управляются софтом Open-E DSS v7.

На хранилищах несколько больших томов. Во-первых, каталоги пользователей+документация. Во-вторых, бухгалтерские базы. В третьих, архив. Ну и наконец, место под виртуальные машины. Собственно, использование iSCSI даёт возможность раскрыть весь потенциал кластера гипервизоров:

  • - мигрирование работающей машины с гипервизора на гипервизор;
  • - при отказе одного из гипервизоров запуск всех VM на другом;
  • - High Availability - мы пока не пользуемся.

Без внешних хранилищ такая схема не могла бы работать, каждая VM была бы прибита к тому гипервизору, на который она установлена. А так мы можем потерять любой из них без ущерба для данных, с некоторой деградацией в скорости, конечно же.

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

Ещё у нас есть сервер приложений, куча виртуалок для разработчиков и всякая обвязка - серверы аутентификации (пара, на всякий случай), внутренний портал и т.п.

Так как и хранилищ, и гипервизоров у нас по паре, объединённых в кластер, то у нас можно вынести ровно половину нашего серверного хозяйства, и мы не пострадаем. Для страховки мы держим половину не в нашем офисе. Таким образом, в случае маски-шоу нам потребуется на восстановление полной работоспособности ровно то время, которое нужно, чтобы поставить новые чистые компы на столы.

На компьютерах сотрудников нет никакой важной информации. Отучали просто - сначала я рассказывал всем, что так делать нельзя. Потом без предупреждений продал пару наугад выбранных компов и поставил новые. Первый раз были стоны: «А где у меня всё?!! - Как где, на сервере, вон в том каталоге, ТЫ ЖЕ ТУДА ЗАПИСЫВАЛА, КАК Я ОБЪЯСНЯЛ? - Ээээээ... Ну да :(». Хватило одного раза всем.

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

Скорость работы всего нашего хозяйства наших пользователей по большей части устраивает. Но всегда есть резервы:

  1. для быстрых данных можно построить RAID10 на скоростных винтах;
  2. можно добавить по одному SSD на каждый контроллер и включить кеширование чтения, есть у Adaptec такая клёвая технология - MaxCache;
  3. добавить памяти в сервер - недорого и эффективно;
  4. вывести SAN в отдельную сеть;
  5. заменить сеть на 10GB
  6. включить в OPEN-E технологию Active-active, в этом случае нагрузка распределяется между хранилищами;
  7. Заменить старый сервер Dual Xeon на что-то более современное - даст прирост производительности на всём кластере. Дело в том, что по умолчанию в кластер можно объединить машины только с совершенно одинаковыми процессорами. Это сделано для обеспечения миграции работающих VM с сервера на сервер. Ведь если машина запустилась на процессоре с одним набором инструкций, и внезапно переехала на другой набор инструкций, мы получим kernel panic или BSoD - на выбор. Есть стандартный хак, который позволяет эту проблему обойти - маскИрование. Каждый процессор сообщает свои возможности, и они урезаются до минимальной совместимости. У нас два сервера из двух совсем разных ветвей развития, и их минимальная совместимость лежит глубоко ниже максимальных возможностей каждого из них, в итоге ни один из серверов не работает на полную мощность.
  8. Эта же замена даст возможность использовать аппаратное ускорение шифрования, которое есть в современных процессорах. Сейчас эти инструкции маскИрованы.

На этом всё. Остались вопросы или хочется обсудить - обращайтесь ко мне или к Юре Бушмелеву.

 
CAPTCHA Image

Все поля обязательны для заполнения

CAPTCHA Image

Все поля обязательны для заполнения