Краткая производственная автобиография
жүктеу/скачать 0.56 Mb.
|
- Бұл бет үшін навигация:
- Электронная версия препринта
- Description of non-production training cluster structure
- Main system
- Dom0 installation and maintenance
- Setup of DomU’s sample
- DomUs creation under sample
- Conclusions
- Literature
Краткая производственная автобиографияПопова Екатерина Валентиновна поступила на работу в ГНЦ ИФВЭ в феврале 2007 года в отдел математики и вычислительной техники после окончания c отличием факультета программного обеспечения вычислительной техники и автоматизированных систем управления по специальности «инженер-программист» Международного университета «Дубна» (филиал «Протвино»). Попова Е.В. является администратором web-сервера института (www.ihep.su), ведет работы по настройке названного сервера, поддерживает систему печати, систему резервного копирования данных и систему информационного обеспечения пользователей сервера. Помимо того, в обязанности Поповой Е.В. входит поддержка функционирования web-сервера: анализ критических ситуаций, и решение технических проблем. Попова Е.В. добросовестно выполняет возложенные на неё задачи администрирования сервера Oracle, на котором хранится база данных пользователей ИФВЭ, и организована система поиска публикаций в НТБ ИФВЭ, обеспечения организации доступа пользователей к данным распределенной файловой системы AFS через web. Поповой Е.В. были выполнены следующие важные задачи: установлен почтовый сервер с повышенной отказоустойчивостью; создан вычислительный кластер из пяти виртуальных машин под управлением Xen-гипервизора; модернизирована система учета трудозатрат в отделе экспериментального производства; мигрированы afs-пользователи со старого сервера на новый; внедрена система мониторинга Nagios для отслеживания работы серверов ИФВЭ. Имеет две печатные работы. За время работы Попова Е.В. зарекомендовала себя грамотным, квалифицированным и ответственным специалистом, умеющим работать в команде, принимать самостоятельные решения. Использование технологии паравиртуализации Xen в ГНЦ ИФВЭ Xen - это монитор виртуальных машин (VMM, Virtual Machine Monitor) или гипервизор (hypervisor) с поддержкой паравиртуализации (para-virtualization) для процессоров x86 архитектуры, распространяющийся с открытым исходным кодом (opensource). Он позволяет нескольким гостевым операционным системам с разными архитектурами выполняться на одной физической машине параллельно. Xen помогает использовать компьютерные ресурсы более эффективно. Варианты использования
В Xen может работать множество гостевых операционных систем, каждая из которых выполнятся в безопасной виртуальной машине. В терминологии Xen такая машина называется домен. Исполнение кода доменов планируется Xen так, чтобы сделать использование доступных процессоров наиболее эффективным. Каждая гостевая ОС занимается управлением собственных приложений. Это управление включает ответственность за планирование выполнения каждого приложения в течение временного интервала, выделенного Xen виртуальной машине. Первый домен, домен 0, создаётся автоматически при загрузке системы. Этот домен обладает особыми управляющими привилегиями. Домен 0 запускает остальные домены и предоставляет им виртуальные устройства. Еще он занимается выполнением административных задач, таких как остановка (suspending), возобновление (resuming) работы виртуальных машин и их миграция. В ИФВЭ первым проектом под xen-ом стала организация не-продакшн кластера с t-инфраструктурой с целью обучения в рамках РДИГа. CE, SE (dCache), WMS/LB, BDII-top, WNs и UI грид сервисы были установлены на одном физическом сервере. На xen0001.ihep.su были установлены 5 гостевых машин плюс главный домен (домен 0). Первая гостевая машина была установлена по сети, остальные 4 клонированы с использованием стандартных средств. В результате было получено: Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 129 2 r----- 102173.7 ce.ngc6475 52 640 2 -b---- 219665.7 se.ngc6475 47 512 2 -b---- 265444.8 ui.ngc6475 50 256 1 -b---- 9835.4 wn01.ngc6475 34 128 1 -b---- 19582.8 wn02.ngc6475 31 128 1 -b---- 19743.5 Описанная система успешно функционирует в ИФВЭ. xen0002.ihep.su стал вторым xen сервером, на котором был опробован перенос работающих на «старом железе» машин под виртуальное управление. На данный момент на нем работают 2 сервера, один из которых mon0002.m45.ihep.su является сервером мониторинга GRID сайта ИФВЭ. На xen0003.ihep.su, первом 64-битном сервере, были развернуты 32-х битные сервера (5), одним из которых стал CMS VOBOX vobox0002.m45. Следующим основным этапом стала реализация кластера из 2-х xen-машин, работающих параллельно – xenihep1.ihep.su и xenihep2.ihep.su., которые должны были обеспечить бесперебойную отказоустойчивую работу важных серверов. Для обеспечения такого режима работы было использовано следующее дополнительное ПО:
В случае отказа одного из серверов, HA (High Availability) Heartbeat система осуществит миграцию виртуальных машин на другой сервер в кластере. Если же необходимо перевести виртуальные машины на другой сервер в штатном режиме, то можно воспользоваться «живой миграцией», когда виртуальная машина не перегружается, а «зависает» на некоторое время, в течение которого по сети происходит копирование состояния оперативной памяти, после чего виртуальный сервер начинает работать на другом сервере (состояние жестких дисков виртуального сервера за счет использования DRBD синхронизовано в кластере). 
Рис.1 Распределение виртуальных машин в кластере 
Рис.2 HA (High Availability) Heartbeat На xen0004.ihep.su была установлена новая версия xen-4, и работают 6 виртуальных серверов, на 4-х из которых установлена операционная система Debian 5 (Lenny), на pps14.ihep.su - SL5.3(Boron), на pps16.ihep.su – Microsoft Windows XP (применялась уже не паравиртуализация, а “железная” виртуализация, т.е. для виртуализации использовался процессор с технологией Intel VT). Такая разнородность в выборе операционных систем объясняется одним из направлений применений технологии xen – виртуальный сервер используется как “песочница” для апробации нового программного обеспечения. Говоря обычным языком – прежде чем что-то обновить на работающем сервере, лучше сначала промоделировать ситуацию на виртуальном. На данный момент в ОМВТ ИФВЭ действуют 6 серверов с использованием xen. 
Рис. 3 Список xen-серверов в ОМВТ ИФВЭ Обоснование важности выдвигаемой работы, возможности и перспективы продолжения этих работ в рамках научно-технической программы ИФВЭВиртуализация серверного оборудования – №1 в списке самых перспективных технологий. Она призвана решать сразу две задачи: понизить стоимость владения серверным парком и одновременно с этим обеспечить высокую доступность и быстрое восстановление после сбоев. Мы используем свободно распространяемый виртуализатор Xen, который обеспечивает максимальную производительность. В дальнейшем мы планируем использовать xen-технологию для создания и тестирования "облачного" решения в рамках ОМВТ ИФВЭ. Облачная обработка данных (англ. Cloud computing) — это технология обработки данных, в которой программное обеспечение предоставляется пользователю как интернет-сервис. Пользователь имеет доступ к собственным данным, но не может управлять операционной системой и собственно ПО, с которым работает (заботиться об инфраструктуре ему также не нужно). Непосредственно "облаком" называют интернет, который как раз и скрывает многие технические детали. Подход к облачным системам различается степенью контроля над низким уровнем, который предоставляется клиенту. Первым уровнем для настоящего Cloud-а будет предоставление виртуализированной среды на базе некоторых стандартных «юнитов», которые по ресурсам могут равняться на определенные реальные железные сервера (сугубо для легкости сравнения и учета). Фактически, выдается виртуальная машина, которая работает на системах провайдера, а внутри нее есть все возможности для установки сначала любой ОС (из поддерживаемых, конечно), а потом уже настройки необходимого ПО. Ограничения такой машины, как уже сказано, выражаются в некоторых приближениях к реальному железу, но, могут гибко и почти мгновенно быть изменены в большую или меньшую сторону.
Berezhnaya A.Ya., Popova E.V. Institute of High Energy Physics (Protvino, Russia) Xen is a virtual machine monitor (VMM) or hypervisor. It allows several guest operating systems with different architectures to be executed on the same computer hardware concurrently. Xen helps to use computer resources more efficiently. It is a free software licensed under GPL2. Non-production cluster with t-infrastructure has been realized under Xen at IHEP to serve training purposes at the Russian Data Intensive Grid consortium (RDIG). CE, SE (dCache), WMS/LB, BDII-top, WNs and UI grid services have been installed at the same server. The experience of cluster construction and usage is discussed.
System installation and adjustment with Xen hypervisor is a solution for many industrial problems such as optimum congestion of computation park, testing new software taking into account various computing platforms and architectures. In the frame of one server we can receive some virtual servers, comparable on productivity with the real one. Description of non-production training cluster structure
Picture 1 - Cluster structure In EGEE Project training grid infrastructure (t-infrastructure) intends for spreading knowledge about Grid Technology. It gives an opportunity for users and system administrators to gain experience in working with Grid. For t-infrastructure in IHEP CE, SE (dcache), WMS/LB, WNs, UI, Site BDII were constructed (Picture 1). User Interface (UI) is a server providing access to Grid resources. Users can start jobs and get results by way of UI. They are able to obtain information about job status, find necessary resources for execution of the specific task. Computing element (СЕ) (Computing Element) is a grid resource node for jobs management (start, submit, execute etc.) It also gives information about resource states. Working Nodes WNs are cluster computing nodes in GRID infrastructure. Storage Element SE (Storage Element) provides uniform access to storage resources. It could be simply a disk servers, large disk arrays or Mass Storage System such as dCache or Castor. Workload Manager System WMS examines Requirements and Rank expressions (and also any data requirements) in the JDL. All CE are filtered against the Requirements, and the Rank is calculated for all the CEs which match and on the basis of Rank determines which CE to submit the job to. For that purpose, the WMS must retrieve information from the IS and the File Catalog Logging and Bookkeeping LB is a Grid service that keeps a short-term trace of Grid jobs as they are processed by individual Grid components. Site BDII (Information Index) is a database server for site resource information. Main systemSome virtual machines can be installed on Xen server. In our case: 5 DomUs and Dom0. Suggested arrangement is shown on picture 2. 
Picture 2 – System schema For task realization we got server with such characteristics: dual-core processor Intel(R) Xeon(TM) CPU 2.80GHz, ROM 4 Gb, 6 iSCSI disks on 73,5 Gb each. Two disks for software RAID1 (mirror) were used under main domain (Dom0). Other disks became base for software RAID5.
For xen we installed two main packages: hypervisor itself (xen-hypervisor-3.0.3-1) and kernel modified for working under xen environment (2.6.18-6-xen-686). During installation all necessary modifications were made in /boot/grub/menu.lst automatically. We faced with problem in pygrub. Pygrub is a Python tool which can look inside a disk image or a filesystem to find a GRUB menu.lst. Then it emulates the GRUB menu and returns the kernel, initrd, boot arguments etc. that GRUB would normally have selected. It’s a way to keep all the kernel stuff inside the guest filesystem so it can be managed as usual by the admin of the guest. Pygrub comes as part of Xen, and on Etch it can be found at /usr/lib/xen-3.0.3-1/bin/pygrub. In xen on Debian Etch in pygrub there were no some files in /usr/lib/xen-3.0.3-1/lib/python/grub/fsys/ext2/. That’s why we downloaded xen sources and copied files from build/lib.linux-i686-2.4/grub/fsys/ext2/*.
lvcreate -L12G -n SL4.7_001 xen0001_guests For DomU SL4.7_001 we edited configuration file /etc/xen/SL4.7_001: name = "SL4.7_001" memory = 256 selinux = 0 disk = [ 'phy:xen0001_guests/SL4.7_001,xvda,w' ] vif = [ 'ip=10.165.1.10' ] on_poweroff = 'destroy' on_reboot = 'restart' on_crash = 'restart' It was downloaded installation kernel and ramdisk from http://linuxsoft.cern.ch/cern/slc4X/i386/images/SL/xen/. The last command was: /usr/sbin/xm create SL4.7_001 -c \ kernel=vmlinuz \ ramdisk=initrd.img \ extra="method=http://linuxsoft.cern.ch/cern/slc4X/i386/" After installation we corrected configuration file adding string for pygrub as a loader. DomUs creation under sampleFor sample designing it was necessary to use kpartx for block device creation of every image parition. Before using kpartx we had to stop DomU. xm shutdown SL4.7_001 We made some block devices: kpartx -v -a /dev/xen0001_guests/SL4.7_001 ls –lah /dev/mapper/xen0001_guests-SL4.7_001p1 ls –lah /dev/mapper/xen0001_guests-SL4.7_001p2. Later we temporally mounted file systems for full dump mount /dev/mapper/xen0001_guests-SL4.7_001p1 /mnt/SL4.7_001/boot/ mount /dev/mapper/xen0001_guests-SL4.7_001p2 /mnt/SL4.7_001/root/ and dumps created themselves. /sbin/dump 0 -L FULL_boot -f /BACKUP-XEN/SL4.7_001_boot.colddump /mnt/SL4.7_001/boot/ /sbin/dump 0 -L FULL_root -f /BACKUP-XEN/SL4.7_001_root.colddump /mnt/SL4.7_001/root/ File systems unmounted. umount /mnt/SL4.7_001/boot/ umount /mnt/SL4.7_001/root/. Bloch devices removed. kpartx -d /dev/mapper/xen0001_guests-SL4.7_001p1 kpartx -d /dev/mapper/xen0001_guests-SL4.7_001p2. These dumps let setup similar DomUs saving time noticeably. Stages:
lvcreate -L10G -n pps11.root xen0001_guests lvcreate -L500M -n pps11.boot xen0001_guests lvcreate -L500M -n pps11.swap xen0001_guests mkfs -t ext3 /dev/xen0001_guests/pps11.root mkfs -t ext3 /dev/xen0001_guests/pps11.boot mkswap /dev/xen0001_guests/pps11.swap
mount -t ext3 /dev/xen0001_guests/pps11.root /mnt/tmp/ cd /mnt/tmp/ restore -rf /root/BACKUP-XEN/SL4.7_001_root.colddump cd ~
umount /mnt/tmp/ mount -t ext3 /dev/xen0001_guests/pps11.boot /mnt/tmp/ cd /mnt/tmp/ restore -rf /root/BACKUP-XEN/SL4.7_001_boot.colddump cd ~
cp /etc/xen/SL4.7_001 /etc/xen/pps11 vim /etc/xen/pps11
mount -t ext3 /dev/xen0001_guests/pps11.root /mnt/tmp/ vim /mnt/tmp/etc/fstab vim /mnt/tmp/etc/sysconfig/network vim /mnt/tmp/etc/sysconfig/network-scripts/ifcfg-eth0 vim /mnt/tmp/etc/hosts umount /mnt/tmp/
xm create pps11 –c We built DomUs for IHEP non-production training cluster in that way. Name ID Mem(MiB) VCPUs State Time(s) Domain-0 0 129 2 r----- 102173.7 ce.ngc6475 52 640 2 -b---- 219665.7 se.ngc6475 47 512 2 -b---- 265444.8 ui.ngc6475 50 256 1 -b---- 9835.4 wn01.ngc6475 34 128 1 -b---- 19582.8 wn02.ngc6475 31 128 1 -b---- 19743.5
Described system adjusts successfully at IHEP for realization of non-production cluster with t-infrastructure. Literature
жүктеу/скачать 0.56 Mb. Достарыңызбен бөлісу:
|