Краткая производственная автобиография



Дата29.04.2016
өлшемі83.23 Kb.

Краткая производственная автобиография


Попова Екатерина Валентиновна поступила на работу в ГНЦ ИФВЭ в феврале 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 – программное обеспечение, осуществляющее контроль за работой виртуальных машин и сетевых дисковых ресурсов в рамках кластерной системы из 2-х компьютеров

  • DRBD (Distributed Replicated Block Device) – система, позволяющая создавать RAID-массивы уровня 1 (зеркальные диски), используя сетевые соединения

В случае отказа одного из серверов, 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-а будет предоставление виртуализированной среды на базе некоторых стандартных «юнитов», которые по ресурсам могут равняться на определенные реальные железные сервера (сугубо для легкости сравнения и учета). Фактически, выдается виртуальная машина, которая работает на системах провайдера, а внутри нее есть все возможности для установки сначала любой ОС (из поддерживаемых, конечно), а потом уже настройки необходимого ПО. Ограничения такой машины, как уже сказано, выражаются в некоторых приближениях к реальному железу, но, могут гибко и почти мгновенно быть изменены в большую или меньшую сторону.

Электронная версия препринта



(NUCLEAR ELECTRONICS & COMPUTING NEC’2009 – Proceedings of the XXII International Symposium)

Xen hypervisor for building of non-production Grid sites

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.
Introduction

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 system


Some 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.

Dom0 installation and maintenance


For main domain (Dom0) we decided to choose Debian 4.0r3 etch i386 as an operating system. Dom0 was setup on two disks joined by RAID1. We had to use two additional disks because of system couldn’t be loaded from RAID5. Two partitions (/ and /boot) were mounted to raid devices /dev/md0 and /dev/md1 accordingly as Grub loader prevented booting from LVM partitions. /dev/md2 became physical volume (PV) for logical volume (LV) XEN0001. With the framework of XEN0001 VG logical volumes were created (for example xen0001-xen0001_home).

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/*.

Setup of DomU’s sample


Primarily we decided to create prototype for DomUs. This sample became base for other DomUs. It was created logical volume SL4.7_001 by 12 Gb in logical group xen0001_guests.

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 sample


For 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:


  1. Logical volume allocation for DomU, file system forming.

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



  1. Dump unwrapping

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 ~


  1. Xen conf file preparation

cp /etc/xen/SL4.7_001 /etc/xen/pps11

vim /etc/xen/pps11



  1. DomU tuning before starting

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/



  1. DomU creation

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

Conclusions


At present Xen hypervisor is widely spread on many enterprises. It may be setup on different hardware and architectures. Xen allows to ensure high productivity for virtual machines. Under Xen it’s possible to create a “sandbox” in which testing of software may be executed.

Described system adjusts successfully at IHEP for realization of non-production cluster with t-infrastructure.



Literature


  1. William von Hagen Professional Xen®Virtualization Published by Wiley Publishing, Inc. 10475 Crosspoint Boulevard Indianapolis, IN 46256

  2. TEST Xen guest domain installation for SLC 4.X / i386 or SLC 4.X / x86_64 https://twiki.cern.ch/twiki/bin/view/LinuxSupport/InstallingXenParaVirtualizedSLC4

  3. Re: Subject: Re: [Fedora-xen] How to backup a Domu filesystem (on LVM) from Dom0 on Fedora 8 ? http://www.redhat.com/archives/fedora-xen/2008-June/msg00011.html

  4. http://linuxforum.ru/index.php?showtopic=89090&pid=830273&mode=threaded&start=#entry830273

  5. Xen and the Art of Virtualization By Paul Barham, Boris Dragovic, Stevan Hand, Tim Harris, Alex Ho, Rolf Neugebauer, Ian Pratt, and Andrew Warfield.Presented by Diana Carroll

  6. http://strugglers.net/~andy/blog/2008/01/20/red-hat-based-linux-under-xen-from-debian-etch/

  7. EGEE – Logging and bookkeeping http://egee.cesnet.cz/cs/JRA1/LB/

  8. GRID Glossary http://www-numi.fnal.gov/offline_software/srt_public_context/GridTools/docs/glossary.html#wms


Достарыңызбен бөлісу:


©dereksiz.org 2019
әкімшілігінің қараңыз

    Басты бет