Как я внедрял первое правило ведения бизнеса в России

«1. Держите сервера за границей»
(с) 9,5 правил ведения безопасного бизнеса в России 

Вводная часть.

Мы — маленькая компания из 10 сотрудников, половина из которых периодически работает удаленно.
Что мы имели изначально: сервер с Windows и терминальным доступом, который стоял в офисе. У всех пользователей были ноутбуки. Никакой особо конфиденциальной информации у нас нет, за исключением важной для бизнеса информации.
В один прекрасный момент меня окончательно «добила» паранойя и было принято решение вынести сервер за пределы офиса.

1) Мы арендовали два сервера: один в Германии, второй — в Нидерландах.
Конфигурации одинаковые: Intel Xeon Quad Core E3-1230 3.20 GHz / 8GB / 2x 1TB.
Обязательными условиями были: IP-KVM 24×7, гарантия ответа техподдержки до 4 часов круглосуточно, гарантия замены сервера на следующий рабочий день (NBD) и безлимитный трафик.
Дополнительные требования к ПО: Windows 2008 standard, Windows 2008 enterprise, терминальные лицензии и MS Office (Word, Excel, PowerPoint)
Эти пожелания и определили достаточно нескромный бюджет: 756 евро/мес.

Хостеров оставим неназванными. Могу только сказать, что из-за желания платить через Webmoney (т.е. не кредитными картами), пришлось обратиться к реселлерам.

2) Настройка обоих серверов на начальном этапе была полностью идентичной. После получения доступа к серверам, весь первый день был потрачен на апдейт ОС. После был установлен Hyper-V.
Сразу же была создана виртуалка на CentOS, которая и стала роутером: именно у неё был «белый» IP. Все остальные машины (в том числе хост-система) работали на «серых» адресах.
Для проведения этого фокуса с IP, нам пригодился постоянно подключенный IP-KVM. В данном случае — встроенный IPMI и iLo на каждом из серверов.
На роутере был поднят Open VPN-сервер, «снаружи» был доступен только он. Все остальные порты были закрыты.
Также на роутере поднят NAT и proxy-сервер.

3) На первом сервере на всю доступную память была создана виртуалка с Windows 2008 Standard, которая стала нашим новым офисным сервером.
7 ГБ для одновременной работы 10 человек в терминале – более чем комфортные условия. Интернет пользователям офисного сервера доступен только через прокси.
Работает Dr.Web, лицензии на который нам достались по подписке от сети, к которой подключен наш офис.
Стандартный набор офисного софта: MS Office, Acrobat Reader, PDF Creator, WinRAR, InfranView, KeePass, Chrome, Firefox.
Чтобы пользователи не путались, всем в автозагрузку был вложен файл Bginfo, который меняет цвет рабочего стола и пишет на нем, что это за сервер.

4) На втором сервере все немного интересней.
На хост-сервере стоит Windows 2008 Enterprise, которая позволяет бесплатно установить до 4-х виртуалок с Windows 2008 Standard.
Таким образом, это, по сути, сервер для бухгалтера: тут работают четыре виртуалки — CRM/биллинг, 1C8 (на нее переходим), 1C7 (с ней работаем), клиент-банк.
Все четыре сервера отделены друг от друга: они находятся в разных виртуальных сетях Hyper-V, которые не могут видеть друг друга.
Так сделано для того, чтобы в ситуации, когда какая-то из машин подхватит какую-то заразу, заражение не распространилось дальше неё.
С этих же машин отправляем отчеты в налоговую через MeDOC и “Податкову звiтнiсть”. Налоговая видит, что отчеты приходят из IP нашего офиса а не из Европы, так как трафик с «бухгалтерских» серверов маршрутизируется через VPN-туннель в офис.
Так же, как и на офисной виртуалке, на серверах с 1С, интернет доступен через прокси, работают Dr.Web’ы и стандартный софт.
В 1С 7ой ключ работает через Usb-over-network, с 1С 8 используем программный ключ.
На сервере клиент-банка интернет отключен: доступ есть только к серверам банков. Банк также видит наш офисный IP а не реальный IP сервера.

5) Все эти серверы доступны через удаленный рабочий стол (RDP) после авторизации на Open VPN-сервере (любом из двух).
И еще один плод моей паранойи: при подключении к Open VPN-серверу невозможно увидеть ни один сервер в своей сети.
По RDP на серверы можно зайти только через нестандартный порт, который «прокидывается» (DNAT) на RDP-порт соответствующей виртуалки.

6) В офисе у нас стоит Wi-Fi роутер D Link DIR-320. Мы перепрошили его, после чего настроили на нем OpenVPN-клиент.
В DIR-320 включен USB-принтер, на который через туннель могут печатать все виртуалки.
Сотрудники из офиса могут работать, ничего не меняя на своих ноутбуках.
Сотрудникам, которые хотят поработать удаленно, выдали ключи Open VPN и следующие инструкции: как настроить туннель на MacOS/Windows, как зайти на удаленный рабочий стол, как печатать на офисный принтер, как печатать на домашний принтер и тому подобное.

7) Самое важное — бекап.
Так как на хост-системах ничего кроме Hyper-V нет, их не бекапим.
В пятницу днем всем сотрудникам приходит рассылка (напоминание о событии от Google Calendar) с просьбой не забыть закрыть все приложения и сохранить все документы.
В ночь с пятницы на субботу Power Shell–скрипт выключает все виртуалки, копирует их VHD-образы в отдельную папку, а откуда копирует на дублирующий сервер через VPN-туннель + на мой сервер в Украине.
Но это только половина дела.
Каждый день на всех виртуалках запускается скрипт, который архивирует изменившиеся за сутки данные; а каждую неделю – архивирует все данные пользователей (действительно все – от документов до 1С-баз).
Архивация происходит по мотивам этой инструкции:habrahabr.ru/blogs/personal/82185/, но архивы мы делаем запароленными, многотомными и с добавлением информации для восстановления. Архивы складываются в премиум-аккаунты DropBox и Google Drive и через эти сервисы попадают на оба сервера (+ директору на ноутбук).

Что имеем в итоге:
— По запросу я могу восстановить любой документ за любой день.
— Все архивы под паролем из сотни случайных символов. Даже если DropBox кому-то опять покажет все свои файлы, мой архив вскрыть будет крайне непросто.
— При каком-либо форс-мажоре с одним из ДЦ, я, чуть меньше чем за час, смогу запустить копию сервера недельной давности на другом сервере в другой стране + накатить изменения из архивов.

Все описанное работает у нас уже почти год. Особых нареканий нет, разве что апдейт ПО на четырех серверах занимает вчетверо больше времени :).
Данные из бекапных архивов пару раз восстанавливал по требованию – работает как часы.
Для теста имитировал несколько раз отключение ДЦ: поднимал все серверы из бекапа на одном из серверов. Все работает, разве что для 1С8 с программным ключом важно сделать полностью аналогичную конфигурацию на новом сервере.
У бухгалтера однажды “слетел” ноутбук, – работу восстановили за пол часа, просто выдав новый и настроив ярлыки для подключения к серверам.
Дата-центры были недоступны несколько раз на пол-часа из-за апгрейда маршрутизаторов, но в рабочее время подобного ни разу не было.
Также однажды была атака на ДЦ в Нидерландах: все «лагало» около часа в рабочее время.
Теоретически можно было бы еще наворотить шифрованные ФС и разнести серверы по разным континентам, но в нашем случае я не вижу в этом никакого смысла.

Надеюсь, эта информация была интересной. Буду рад если она кому-то пригодится.
Если решите повторить такую конфигурацию, не стесняйтесь спрашивать: я с удовольствием помогу советом и раскрою какие-либо неочевидные подробности.

http://habrahabr.ru/post/157899/#habracut

SMP-affinity

Не многие знают, что они могут значительно повысить производительность сетевой подсистемы Linux на мультипроцессорных или многоядерных системах за счёт распределения системных прерываний от сетевых адаптеров на различные процессоры/ядра.

Дело в том, что при интенсивной сетевой нагрузке сетевые платы вызывают слишком много системных прерываний (Вы можете посмотреть нагрузку на процессоры Вашего сервера создаваемую обработкой системных прерываний с помощью утилиты top – параметр si), что влечёт за собой потерю пакетов проходящих на/через сетевые интерфейсы.

Допустим, что у Вас в системе есть два процессора и два сетевых адаптера, сделаем так, чтобы системные прерывания от eth0 обрабатывались первым процессором, а прерывания от второго сетевого адаптера eth1 обрабатывались вторым процессором.

Проверим как обрабатываются прерывания от сетевых адаптеров в данный момент: cat /proc/interrupts

           CPU0       CPU1
  0: 1025359421 1011223877    IO-APIC-edge  timer
  1:          7     443237    IO-APIC-edge  i8042
  6:          3          2    IO-APIC-edge  floppy
  7:          0          0    IO-APIC-edge  parport0
  8:          0   18718112    IO-APIC-edge  rtc
  9:          1          0    IO-APIC-level  acpi
 12:   11950434        756    IO-APIC-edge  i8042
90:      790345          0    IO-APIC-level  eth0
169:         69   10339595    IO-APIC-level  uhci_hcd:usb5, HDA Intel, i915@pci:0000:00:02.0
177:          79073095  0     IO-APIC-level  eth1
209:          0          0    IO-APIC-level  uhci_hcd:usb4
217:     212348          1    IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
225:   24498064       3245    IO-APIC-level  uhci_hcd:usb3, libata
NMI:          0          0
LOC: 2036559271 2036559270
ERR:          0
MIS:          0

как мы можем видеть в приведённом примере первый сетевого адаптер «висит» на IRQ 90, а второй на IRQ 177. Причём явно видно что прерывания как от первого, так и второго сетевого адаптера обрабатываются первым процессором в системе.

Исправим данную ситуацию, для этого нам необходимо записать число “2″ в файл /proc/irq/177/smp_affinity

echo "2" >/proc/irq/177/smp_affinity

после этого посмотрим как изменилась ситуация:

cat /proc/interrupts
           CPU0       CPU1
  0: 1025359421 1011223877    IO-APIC-edge  timer
  1:          7     443237    IO-APIC-edge  i8042
  6:          3          2    IO-APIC-edge  floppy
  7:          0          0    IO-APIC-edge  parport0
  8:          0   18718112    IO-APIC-edge  rtc
  9:          1          0    IO-APIC-level  acpi
 12:   11950434        756    IO-APIC-edge  i8042
90:      790345          0    IO-APIC-level  eth0
169:         69   10339595    IO-APIC-level  uhci_hcd:usb5, HDA Intel, i915@pci:0000:00:02.0
177:   79073095    3672362    IO-APIC-level  eth1
209:          0          0    IO-APIC-level  uhci_hcd:usb4
217:     212348          1    IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
225:   24498064       3245    IO-APIC-level  uhci_hcd:usb3, libata
NMI:          0          0
LOC: 2036559271 2036559270
ERR:          0
MIS:          0

как видим счётчик прерываний для eth1 на CPU0 не изменился, но появились цифры ниже CPU1 т.е. обработка прерываний от второго сетевого адаптера eth1 обрабатывается вторым процессором в системе.

Небольшое объяснение насчёт того, что же значит цифра 2 !
Linux каждому cpu в системе ставит в соответствие некую цифру обозначающую данный процессор в системе. Ниже приведена таблица для 4-х процессорной системы

            двоичный    шестнадцатеричный
    CPU 0    0001         1
    CPU 1    0010         2
    CPU 2    0100         4
    CPU 3    1000         8

т.е. если бы у нас в вышеприведённом примере было не 2 а четыре процессора и мы бы хотели обрабатывать прерывания от eth1 на третьем процессоре CPU2, то нам для этого пришлось бы вместо 2 записать цифру 4 в файл /proc/irq/177/smp_affinity .

Любознательный читатель может спросить, что же было бы если бы мы записали в данный файл число которого нет в приведённой таблице, например echo “3″ >/proc/irq/177/smp_affinity. Ответ прост прерывания от eth1 обрабатывались бы первым и вторым процессором т.к.

           двоичный     шестнадцатеричный
    CPU 0    0001         1
  + CPU 2    0010         2
    -----------------------
             0011         3

Стоит особо отметить, нет смысла обрабатывать системные прерывания от одного сетевого адаптера на нескольких процессорах/ядрах т.к. суммарно system interrupts от данного адаптера никогда не превысит 100%, т.е. максимум, что Вы сможете получить это 50% загрузки на одном процессоре/ядре и 50% на другом.

Дополнение: у компании Intel существуют чипсеты 82575 и 82576 сетевые карты на базе которых имеют несколько очередей каждая из которых может обрабатываться отдельным ядром/процессором.

Выглядит это следующим образом

cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
  0:   72718527   72693470   72701000   72694778   72698856   72705975   72697612   72709066    IO-APIC-edge  timer
  1:          0          1          0          0          0          0          1          0    IO-APIC-edge  i8042
  6:          0          0          2          0          0          0          1          0    IO-APIC-edge  floppy
  8:          0          0          0          0          0          1          0          0    IO-APIC-edge  rtc
  9:          0          0          0          0          0          0          0          1   IO-APIC-level  acpi
 14:     143672     144923     144966     146156     144955     144426     144156     144955    IO-APIC-edge  ata_piix
 15:     892735     915776     908202     913235     910358     903767     912399     900143    IO-APIC-edge  ide1
 58:          0          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb3
 66:         64          0          0 2259148530          0          0          0          0       PCI-MSI-X  eth0-tx0
 74: 2992330737          0          0          0          0          0          0          0       PCI-MSI-X  eth0-rx0
 82:       4197 3028991669          0          0          0          0          0          0       PCI-MSI-X  eth0-rx1
 90:       4091          0 3008220806          0          0          0          0          0       PCI-MSI-X  eth0-rx2
 98:       4092          0          0 2999334745          0          0          0          0       PCI-MSI-X  eth0-rx3
106:          2          0          0          0          0          0          0          0       PCI-MSI-X  eth0
114:          7          0          0          0          0          0          0 2265679966       PCI-MSI-X  eth1-tx0
122:          1          0          0          0 3906833163          0          0          0       PCI-MSI-X  eth1-rx0
130:          1          0          0          0          0 3957703625          0          0       PCI-MSI-X  eth1-rx1
138:          1          0          0          0          0          0 3918250115          0       PCI-MSI-X  eth1-rx2
146:          1          0          0          0          0          0          0 3928688764       PCI-MSI-X  eth1-rx3
154:          2          0          0          0          0          0          0          0       PCI-MSI-X  eth1
169:          0          0          0          0          0          0          0          0   IO-APIC-level  uhci_hcd:usb5
177:          1          0          0          0          1          1          1          1   IO-APIC-level  uhci_hcd:usb4, aic94xx
185:          0          0          0          0          0          0          0          0   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2
NMI:          0          0          0          0          0          0          0          0
LOC:  581643579  581643516  581643609  581643411  581643494  581643475  581643531  581643008
ERR:          0
MIS:          0

За данную информацию спасибо Marian Ivasiuk

Подробнее прочитать о SMP-Affinity можно по этому адресу http://www.cs.uwaterloo.ca/~brecht/servers/apic/SMP-affinity.txt
http://centos.alt.ru/?p=26