 |
|
|
|
Виртуализируем предприятие. Чтобы заработала бухгалтерия
Виртуализируем предприятие Ожидания и уверения правительств разных стран в том, что кризис вот-вот закончится (или уже где-то закончился), как-то не укладываются в реальную ситуацию. Системный администратор, как собака: всё понимает, только сказать не может... Из устного фольклора Что делать, когда не знаешь, что делать? А реальная ситуация такова: все ещё больше стали экономить на всем (даже правительство «ненавязчиво» предлагает всем нам дружно перейти на энергосберегающие лампочки), бюджеты ИТ-отделов, и не только, срезают, людей увольняют или отправляют в бессрочный неоплачиваемый отпуск пачками. Программы по обновлению и расширению компьютерного парка заморожены. Самое интересное и парадоксальное в этой ситуации – работы для всех стало больше, и это, на мой взгляд, прямое следствие изменений в штатных расписаниях предприятий и организаций, но сейчас не об этом. Как гласит одна поговорка: «Хороший начальник – это тот начальник, о котором вспоминают только в день зарплаты». Так вот, по моему мнению, про службу ИТ или про системного администратора (в зависимости от размера компании) вспоминают, когда что-то перестает работать или хочется уменьшить расходы за счет ИТ-отдела. До сих пор существует мнение, что «они» – это что-то среднее между завхозом, кладовщиком и электриком (уборщицей, поваром, охранником и т.п. – нужное подчеркнуть). Чем занимаются – непонятно, а значит, не очень нужны, и деньги давать им не стоит. Переломить эту позицию удается не всем. Приговор часто выглядит примерно так: «Мы же в прошлом году новый сервер покупали, разве нельзя на нем бухгалтерию «крутить», сейчас денег нет...» И начинаются долгие объяснения про то, что «новый сервер покупали для контроллера домена, так как старый девятилетней давности, HP уже ну никак не справлялся – ни памяти, ни дискового пространства», что «бухгалтерию в целях безопасности необходимо выделить в отдельную подсеть, организовав средствами коммутатора VLAN» и что им в этой сети необходим сервер баз данных. При этом умалчивая, что еще желательно DNS + DHCP. В итоге, как обычно, все остается по-прежнему за исключением того что «бухгалтерия должна работать!». И вот в такой непростой ситуации для администратора вопрос, что делать, становится главным: отказаться от своих лучших побуждений – отделения бухгалтерской подсети от основной массы пользователей, тем самым защищая конфиденциальную информацию, или искать другие решения? Недавно и мне пришлось искать решение подобной задачи, о чем и хочу рассказать. В общих чертах я уже обрисовал задачу, теперь уточню:
Рисунок 1. Схема сети после модернизации Имеющееся оборудование и лицензии на программное обеспечение:
На сервере была развернута служба AD и все необходимые сервисы, а также сконфигурированы и настроены сетевые диски. Все прекрасно, если бы не бухгалтерия. Где взять еще один сервер? Вспоминаю, что сервер поддерживает аппаратную виртуализацию, и принимаю решение виртуализировать. Вопрос только, на какой платформе. Начинаю перебирать: VMware Server, VirtualBox, Microsoft VirtualPC, Parallels Workstation, Xen, Hyper-V, Citrix XenServer, KVM. VirtualBox, Microsoft VirtualPC, Parallels Workstation – сразу отвергаю как платформы, в основном «заточенные» для рабочих станций, а VirtualBox 3.0 еще и сыроват – проблемы с виртуализацией сети. VMware Server и Hyper-V отпадает из-за платности. В чистом остатке – Xen, Citrix XenServer, KVM. С Xen и Citrix XenServer я уже давно имел дело, поэтому свой выбор остановил на них, а вот KVM решил не рассматривать в связи с тем, что с ней пока не работал. Подготовка В начале мая 2009 года компанией Citrix Systems был анонсирован Citrix XenServer 5.5.0, который основан на третьей ветке Xen. Сейчас он доступен для загрузки по адресу http://www.citrix.com/lang/English/lp/lp_1688615.asp. Также нам понадобится ISO-образ с драйверами для Windows и Linux-гостевых систем Linux Guest Support и XenCenter, которые тоже доступны для загрузки с этой страницы. Как контроллер домена DHCP и DNS для сети бухгалтерии (buh.firma.ru) будем использовать openSUSE 11.1 Скачиваем по адресу http://download.opensuse.org/distribution/11.1/iso/openSUSE-11.1-DVD-x86_64.iso. Мне эта ОС нравится за немецкое качество и замечательный инструмент настройки и конфигурирования Yast. Для переноса физического сервера в виртуальную среду Citrix Systems рекомендует воспользоваться утилитой XenConvert 2.0.2, которую можно скачать по адресу http://citrix.com/English/ss/downloads/results.asp?productID= 683148. Но воспользоваться ею можно, только если в вашей сети уже есть установленный Citrix XenServer. Ещё один минус, который был обнаружен – утилита не в состоянии скопировать блокированные системой DAT-файлы AD с работающего сервера. И, как следствие, мы можем с ее помощью получить неработающий контроллер AD. В связи с этим было принято более сложное решение – установить уже в виртуальной машине сервер, а затем восстановить резервную копию AD. Минус решения – пришлось устанавливать все необходимые программы заново и делать некоторые настройки. Плюс – система чиста от ненужных теперь драйверов физических устройств. Еще один вариант: использовать Acronis True Image для создания vdi-образа, а затем этот образ импортировать в Citrix XenServer (для такого решения удобно использовать Live CD – Yurkesha BartPE, который можно скачать по адресу http://yurkesha.seclorum.ru/main_ru.html). Были еще несколько вариантов, но все они занимают примерно одно и то же время и одинаковы по трудоемкости. В конкретной ситуации для меня оказалось проще так. Все работы были запланированы на субботу, поэтому к окончанию работы в пятницу был сделан бэкап всех данных сервера на внешний жесткий диск емкостью 1 Тб. Затем на этот жесткий диск копируем в корень ISO-образы Windows Server 2003 R2, openSUSE 11.1, Linux Guest Support и Yurkesha BartPE, они нам понадобятся для установки виртуальных систем. Настройка коммутаторов Создаем на обоих коммутаторах подсеть VLAN1. Добавляем в эту подсеть все порты первого и второго коммутатора за исключением портов, к которым подсоединены компьютеры бухгалтерского отдела. Свичи подключены друг к другу по порту 1 Гбит (свитч №2 – 49 порт и свитч №1 – 3 порт), поэтому для проброса тегированного трафика их необходимо добавить в сеть VLAN2 и тегировать трафик на порту первого свича, к которому подключен сервер, в моем случае порт №4. Для этого подключаемся к свичу №2: # telnet 192.168.1.242 Вводим логин и пароль, переходим в меню bridge, а затем в меню vlan:
Выбираем создать VLAN (create), вводим номер VLAN – 2 и имя:
После этого при помощи modify добавляем необходимые порты в подсеть VLAN2:
По окончании добавления портов в подсеть VLAN2 на втором свиче должно получиться что-то вроде этого:
Здесь порты с 42 по 48 – это и есть подсеть бухгалтерии, они подключены только в VLAN2. С этим коммутатором все. На свиче №1 добавляем VLAN2. Порты, которые необходимо включить в эту сеть (порт 3, идущий из свича №2, и порт 4, который подключен к серверу виртуальных машин), переводим в режим hibrid, а затем добавляем их в VLAN2. Все эти действия достаточно удобно производить через веб-управление. В итоге должна получиться такая картина, как показана на рис. 2, 3, 4.
Рисунок 2. Две подсети в коммутаторе
Рисунок 3. Подготавливаем тегированные порты
Рисунок 4. Зеленые порты тегированы тегом 2 (VLAN002) Подключаем сетевые интерфейсы сервера соответственно eth0 в любой порт, а eth1 в порт 3, который «смотрит» в VLAN2 (см. рис. 4). Объясню, почему нельзя было подсоединить сразу во второй свитч, он просто банально находится не в серверной, а на другом этаже, и к нему подключены не только машины бухгалтерии, но и основная масса остальных рабочих станций. Устанавливаем Citrix XenServer, при установке не забываем указать «Установить xen-tools» и задать для eth0 IP-адрес в диапазоне первой (существующей) сети VLAN1. По окончании установки и перезагрузке проверяем в консольном меню IP-адрес и остальные параметры конфигурации сервера. Если все в порядке, то можем переходить к своему рабочему месту. Все остальные операции будем производить удаленно с помощью XenCenter. Инсталлируем на рабочем компьютере администратора XenCenter и подключаемся к серверу по указанному при установке IP-адресу (см. рис. 5).
Рисунок 5. Подключение к Citrix XenServer Подключаем внешний диск к машине администратора и расшариваем для доступа на чтение весь диск под именем iso или как кому нравится. Вызываем вкладку New Storage в XenCenter, создаем репозиторий типа ISO library – Windows File Sharing (CIFS) и жмем Next (см. рис. 6).
Рисунок 6. Добавление ISO-репозитория На следующей вкладке указываем IP-адрес машины администратора, название директории, имя и пароль пользователя для подключения и жмем Finish (см. рис. 7).
Рисунок 7. Параметры подключения к машине администратора Теперь в центре управления должен появиться локальный ISO-репозиторий, содержащий дистрибутивы (см. рис. 8), используя который будем создавать виртуальные машины.
Рисунок 8. Вид XenCeter с подключенным ISO-репозиторием Создаём виртуальную машину, выбрав шаблон Windows 2003-32, подключив ISO-образ дистрибутива и изменив размер локального диска по своему усмотрению. Я посчитал, что для моей системы для диска «C» вполне хватит 30 Гб. Остальные диски для рабочих групп добавим и настроим позже. Затем переключаемся на вкладку Console виртуальной машины и выполняем установку системы. По окончании установки выбираем из раскрывающегося списка в качестве DVD Drive образ xs-tools.iso и устанавливаем драйвера системы для улучшенной поддержки виртуальной машины. Перегружаемся и добавляем роли dhcp и dns, не настраивая, затем выполняем восстановление AD. Операция восстановления или создания контроллера домена из резервной копии подробно описана на сайте microsoft.com, а также на многих сайтах в Интернете. Потому не буду подробно останавливаться на этом вопросе. Перегружаем сервер, проверяем работу служб, затем выключаем. Виртуальный коммутатор в Citrix XenServer позволяет создавать виртуальные сети VLAN. С помощью XenCenter делать это одно удовольствие. Заходим на вкладку меню Network. Отмечаем тип External Network, указываем имя сети – Buh, выбираем физический интерфейс (NIC), указывая на ту сетевую карту (в нашем случае eth1), которая смотрит в тегированный порт, и назначаем ей VLAN, равный 2 (см. рис. 9).
Рисунок 9. Создание тегированного сетевого интерфейса Вот и все! Теперь у нас есть виртуальный сетевой адаптер, который видит только сеть VLAN2. Его и используем при создании виртуальной машины для бухгалтерии. В стандартных шаблонах XenCenter нет openSUSE 11.1 – выбираем SUSE Linux Enterprise Server 11 x64 или создаем конфигурацию сами, как кому нравится, исключение составляет только размер виртуального диска, нам понадобится не меньше 30 Гб (20 Гб под базы данных и бэкапы и 10 Гб под систему, по умолчанию – всего 8 Гб). Установка openSUSE 11.1 описана много раз и не представляет никакой сложности, поэтому не будем на ней подробно останавливаться, за исключением нескольких моментов. При стандартном автоматическом разбиении дискового пространства утилита установки предложит создать отдельные разделы для корня файловой системы, папки home и диска подкачки swap. Я, исходя из собственного опыта, предпочитаю создавать разметку для openSUSE 11.1 на основе LVM приблизительно с такими параметрами: 1-2 Гб – под swap, 30?70 Мб – для boot, 8-10 Гб – для /, остальное распределяю между /srv и /var. Я не претендую на то, что это лучший вариант, просто мне так удобней, у вас может быть все по вашему желанию. Важное преимущество при использовании LVM – возможность в любой момент добавить еще один физический том в любую группу томов, а также свободно менять размеры разделов. Причем все операции можно производить «на горячую», не останавливая работы сервера. Такой вариант разметки очень удобен для виртуальной машины – когда возникнет необходимость, всегда можно увеличить размер дискового пространства любого раздела. При выборе устанавливаемого программного обеспечения обязательно отмечаем для установки:
Устанавливать или нет графику – это решать вам, но мое мнение, что с Yast-ом быстрее и удобнее работать при помощи мыши, хотя все действия можно выполнять с помощью функциональных клавиш, <TAB> и <Shift>. Для серверов можно ограничиться минимальным набором «графики» XFCE. Также на время настройки сразу при установке советую отключить файервол. По окончании установки и перезагрузке выполняем установку xs-tools.iso, подключив в DVD xen-tools. Для этого проверяем существование устройства командой: fdisk -l затем монтируем найденное устройство и запускаем скрипт установки install.sh (см. рис. 10).
Рисунок 10. Установка xen-tools на гостевую машину Если в вашей версии скрипт завершится с ошибкой, то просто установите соответствующий rpm-пакет: rpm -ivh xe-guest-utilities-5.5.0-458.x86_64.rpm После установки обязательно требуется перезагрузка системы. Имя сервера устанавливаем buh, домен firma.ru. В настройках сетевой карты присваиваем статический IP-адрес 192.168.2.1 и переходим к настройкам DNS. Создаем с помощью Yast прямую firma.ru и обратную 2.168.192.in-addr.arpa зоны. Добавляем NS- и A-записи, указывающие на сервер 192.168.2.1 с именем buh. Не забываем указать или заново создать TSIG Key для дальнейшего динамического обновления с помощью DHCP. Сохраняем настройки. Заходим в настройку DHCP, задаем диапазон раздаваемых адресов и обязательно указываем синхронизировать данные с DNS-сервером. При выборе этой опции Yast предложит автоматически или в режиме мастера создать (модифицировать) DNS-зону – смело соглашайтесь. Выбираем расширенную конфигурацию, затем необходимую зону и в ней управление динамическим DNS (Configured Declarations -> Subnet -> Edit -> Dynamic DNS), включаем динамическое обновление, указываем TSIG Key для зон и их название, жмем Save. Перезапускаем серверы. Все, связка DHCP + DNS настроена. Перед дальнейшей настройкой желательно проверить их работу, включив любой компьютер из VLAN2, и убедиться, что IP-адрес и имя компьютера появятся в DNS и будут резолвиться. Переходим в Yast на вкладку Network Services и справа выбираем закладку Samba Server. На вопрос о типе выбираем контроллер домена и заполняем необходимые поля, здесь же можно включить Wins для поддержки старых систем. Запоминаем пароль суперпользователя root на Samba – с его помощью будем добавлять компьютеры в рабочую группу, и сохраняем настройки (см. рис. 11).
Рисунок 11. Создание рабочей группы с помощью Yast В стандартной конфигурации Samba профили пользователей Windows хранятся на сервере, нам это не нужно, поэтому сразу правим файл /etc/samba/smb.conf. Строку: logon home= \\%L\%U\.9xprofile меняем на: logon home= '' Строку: logon path =... комментируем. В строке: logon scrip = start.bat указываем имя файла, который будет запускаться при старте системы. Этот файл должен располагаться в каталоге: /var/lib/samba/netlogon. У меня он просто монтирует общий для всех пользователей каталог и содержит: net use W: \\buh\distrib Для осуществления желаемого необходимо создать папку /HOME/distrib. Выставить на нее права: chmod 755 /home/distrib и изменить группу владельцев на нее: chown –R root:users /home/distrib В файле /etc/samba/smb.conf этот каталог описываем как общий для чтения и доступный всем группам и пользователям, за что отвечает директива public: # Описываем шары[distrib] comment = all users share path = /home/distrib public = yes writable = yes valid users = firma.ru\users create mask = 0744 В такой конфигурации подразумевается, что ограничения прав записи на файловую систему не дадут простым пользователям изменять или записывать файлы, а администратор домена всегда сможет изменить любой файл или каталог. Сейчас Samba имеет огромное количество параметров настройки, таких как выполнение скриптов загрузки, динамические изменения в реестре, установка и публикация принтеров, поддержка расширенных прав на файловую систему и т.д. Если хотите быть в курсе последних изменений, стоит заново перечитать документацию на нее. Добавление пользователей происходит в два этапа. Сначала добавляем через Yast – «Управление пользователями» всех пользователей сети «Бухгалтерия», а затем, запуская из командной строки скрипт: smbpasswd <имя пользователя> который создает пары логин-пароль в файле /etc/samba/smbpasswd, в нем также можно прописать дополнительные алиасы имен пользователей. Компьютеры в домен добавляем как обычно, за исключением использования логина администратора, вместо него используем root, как показано на рис. 12. Из консоли XenCenter запускаем первый сервер kdc.firma.ru. На этом основная настройка окончена.
Рисунок 12. Ввод машины в рабочую группу Осталось создать и добавить дополнительные диски для групп пользователей, а также назначить им права. Скопировать данные с переносного жесткого диска. Установить на сервер бухгалтерии SQL Anywhere Studio для Linux и запустить на нем базу данных бухгалтерии. Подключить принтер к серверу бухгалтерии, и можно работать. *** Модифицировать и развивать эту конфигурацию очень просто. Можно легко создавать полные резервные копии установленных серверов. В любой момент делать снимки состояния систем. Создать и скопировать на внешний носитель шаблоны работающих систем для быстрой установки ОС, на которых можно отрепетировать определенные критические действия, такие как установка сервис-паков и т.п. Все ограничено только вашей фантазией, а простор для экспериментов открывается огромный. Удачи, буду рад вопросам и отзывам на форуме журнала по адресу www.samag.ru/forum.
|
СЕРГЕЙ КРУТСКИХ, старший системный администратор компании «ИНФИН», занимается администрированием серверов, работающих под управлением Windows Server 2003, FreeBSD, openSuSe, OpenBSD
Комментарии отсутствуют
| Добавить комментарий |
|
Комментарии могут оставлять только зарегистрированные пользователи |
|
