Автоматизированные системы обработки информации и управления

Российский  Государственный  Социальный Университет

Кафедра "Автоматизированные системы обработки информации и управления"            

Отчет

О прохождении______производственно-технологической_________практики

Студентом                         Габлая Кобы Зазаевича

(Ф.И.О.)

Факультета________________________________________________________

Специальности      "Автоматизированные системы обработки информации и управления"

Курса___4____Формы  обучения______очная______Группы__04- АСУ___

В компании ООО ”Айти  сервис” в качестве веб-разработчика.

(должность,  наименование организации (предприятия))

с « 15 » ______июня_______ 2011 г. по « 12 » ______июля_______ 2011 г.

 
 

Подпись студента

_____________________________                   ____________________________                                            

             (подпись)                                                 (Ф.И.О.)

                                          «___» ___________________ 2011  г.

Подпись руководителя

Практики  от организации

(предприятия)

_____________________________                   __________________________

             (подпись)                                                 (Ф.И.О.)

                                          «___» ___________________ 2011  г.

Подпись руководителя

практики  от Университета

___________________________                       ____________________________

             (подпись)                                                 (Ф.И.О.)

                                          «___» ___________________ 2011  г.

Отчет принял

Заведующий  кафедрой

___________________________                       ____________________________                                                    

             (подпись)                                       (Ф.И.О.)

                                          «___» ___________________ 2011  г.

 
 
 
 
 

Содержание

          Дневник производственной практики…………………………………..3

 

          Индивидуальное задание студента на практику…………………….....8

 

     Введение……………………………………………………………..…...9

     Глава 1. «Айти Сервис»  ………………………………………….…. 10

          1.1 Сведения об фирме……………………………………………....…10

     1.2 Защита конфиденциальной информации  в сети……………….…11

          1.3 Аппаратные и программные средства в компаний……….………12         

         

          Глава 2. Описание работ, выполненных в период практики……16

 

2.1 Изучение  панелей управления хостингом…………………….…..16

 

2.2 Установка  Cpanel..............………………………………………..…19

 

2.3 Ознакомленние  с операционной системой Centos 5.4..….……….22

 

4. Ознакомленние с операционной системой LinuxCloud.………….23

 

5.  Изучения и инстяляция систем управления

DataLifeEngine, WordPress, Joomla.…………………................…………...…24

 

     Заключение студента по итогам практики………….…………………29

 

     Отзыв…………………………………………………………....……......30

          Приложение...............................................................................................31

     Список  литературы……………………………………………………...31

 
 
 

Российский  Государственный  Социальный Университет

филиал  в г. Сочи

 

Дневник производственной  практики

 
 
 

Студента                   Габлая Кобы Зазаевича

(Ф.И.О.)

 

Факультет    Экономики и АСУ

Специальность            «Автоматизированные системы обработки информации и управления»

 

Курс           4         Форма обучения       Очная        

Группа         04-АСУ            № зачетной книжки           3285

 

Руководитель  практики от

Университета

 

________«АСУ»________

(наименование кафедры)              (Ф.И.О.)

 
 
 
 
 

Руководитель  практики от организации

(предприятия)                                                                

                                                                  (Ф.И.О.)

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Календарный график (план) прохождения  практики.

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Введение

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

     Она являлась подготовкой к работе с  аппаратными и программными компонентами локальных вычислительных сетей.

Я, Габлая Коба Зазаевич прошел производственную практику  с 15.06.2011 по 12.07.2011 в ООО ”Айти сервис” в качестве веб разработчика.

В своем  отчете я описываю структуру, работу, сферу области деятельности ООО  ”Айти сервис”.

 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

      

  Глава 1. «Айти сервис»

1. Сведенья фирмы.

Компания ООО ”Айти сервис” была создана в начале 2011 году. До этого все программисты студии занимались разработкой программного обеспечения как free lance, на протяжение 3-4 лет. И после того как мы набрали определенный опыт была открыта официально компания. 
Наша студия занимается продажей и разработкой программного обеспечения. 
Большой приоритет мы ставим на веб программирования (PhP, MySQL) ну и вторым номером у нас является разработка на C#. 
Все наши продукты как купленные так и заказанные идут с вечной гарантией на исправления ошибок и уязвимостей. 
По желанию мы совершенно бесплатно поможем вам составить грамотное техническое задание. 
Мы всегда рады осуществлять бесплатную поддержку наших продуктов. 
Наша студия ставит перспективу на молодых специалистов.

Реквезиты компании -

ООО “Айти Сервис” 
ОГРН: 1112365000164 
ИНН: 2365017455 
Расчетный счет: 40702810100320000010 
Корреспондентский счет: 30101810000000000715 
БИК: 040349715 
Наименование банка: Банк «Первомайский» (ЗАО)г.Краснодар

Адрес:

Туапсе, Россия, 352800 
ул.Маршала Жукова, д.3, офис 309

Телефон:

8 (86167) 70817

 
 

   

1.2 Система безопасности  на серверах  ООО  ”Айти сервис”

На серверах выключен root доступ а управления используется исключительно по панели управления Cpanel или SSH доступы которые привязанны к определенным ip а подключения к управлению происходит через голые VPS построенные на техналогии XEN или Hyper V а так же выполнен сложный тюнниг - с оптимизации часто используемых услуг, таких как HTTP / Apache, FTP, DNS Bind и SSH, антивирус ClamAV

 

         

         

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

1.3Аппаратные  и программные  средства в офисе.

     В офисе представительства  имеются 5 персональных компьютера и 2 выделенных серверов на которых происходит вся  работа, сервера расположенны удаленно в дата центре Хетзнер Онлайн (Франфуркт  на майне, Германия) и М9 (Москва)

 

ПК № 1

AMD PHEMON 2 X4 945, Dell HDD 146GB 2.5" SAS HS 15K T610R610R710 под о.с и под хранение данных 1.5 TB SEAGATE SATA 2, 8 Гб Ram ddr3

Операционная  система Windows 7 Максимальная

ПК № 2

AMD PHEMON 2 X4 945, Dell HDD 146GB 2.5" SAS HS 15K T610R610R710 под о.с и под хранение данных 1.5 TB SEAGATE SATA 2, 8 Гб Ram ddr3

Операционная  система Windows 7 Максимальная

ПК № 3

AMD PHEMON 2 X4 945, Dell HDD 146GB 2.5" SAS HS 15K T610R610R710 под о.с и под хранение данных 1.5 TB SEAGATE SATA 2, 8 Гб Ram ddr3

Операционная  система Windows 7 Максимальная

 

ПК № 4

AMD PHEMON 2 X4 945, Dell HDD 146GB 2.5" SAS HS 15K T610R610R710 под о.с и под хранение данных 1.5 TB SEAGATE SATA 2, 8 Гб Ram ddr3

Операционная  система UBUNTU 10.11

 

ПК № 5 под VPS

AMD PHEMON 2 X4 945, Dell HDD 146GB 2.5" SAS HS 15K T610R610R710 под о.с и под хранение данных 1.5 TB SEAGATE SATA 2, 16 Гб Ram ddr3

Операционная  система Windows Hyper V

 
 
 
 
 
 
 
 

Выделенные сервер №1 (Франфуркт на майне)

Intel®  Xeon® E3-1275 Quad-Core inkl. Hyper-Threading-Technologie, 16 GB DDR3 RAM ECC, 1 GBit OnBoard mit 100 MBit-Anbindung, 2 x 3 TB SATA 6 Gb/s HDD 7200 rpm (Software-RAID 1)

Операционная  система LinuxCloud + Cpanel + LiteSpeed

 

Выделенные  сервер №2 (Москва)

AMD Athlon 64 X2 6000+, 4x 2048 MB DDR2-667 PC-5300 RAM, 2x 750 GB SATA HDD (Software-RAID 1)

Операционная система Centos 5.4 + Cpanel + Apach

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Глава 2. Описание работ, выполненных  в период практики.

1. Ознакомление с техналогией XEN

Xen — кросс-платформенный гипервизор, разработанный в компьютерной лаборатории Кембриджского университета и распространяемый на условиях лицензии GPL. Основные особенности: поддержка режима паравиртуализации помимо аппаратной виртуализации, минимальность кода самого гипервизора за счёт выноса максимального количества компонентов за пределы гипервизора.

 

Области применения

 

Технология виртуальных  машин позволяет расширить функциональность оборудования следующими способами:

Виртуальная машина обладает производительностью, сравнимой  с реальной.

Возможность миграции запущенной виртуальной машины между  физическими машинами.

Хорошая поддержка  оборудования (поддерживается большинство  драйверов устройств Linux)

Возможность создания песочницы, перезагружаемые драйверы устройств.

 
 

Терминология

 

Основной концепцией гипервизора является домен. Доменом  называется запущенная копия виртуальной  машины. Если виртуальная машина перезагружается, то её домен завершается (в момент перезагрузки) и появляется новый  домен. Более того, даже при миграции содержимое копируется из одного домена в другой домен. Таким образом, за время своей жизни практически все виртуальные машины оказываются по очереди в разных доменах. Xen оперирует только понятием домена, а понятие «виртуальной машины» появляется на уровне администрирования (прикладных программ, управляющих гипервизором).

Домены бывают нескольких типов. Самые известные dom0 и domU. dom0 —  первый запущенный Xen домен, обычно он автоматически создаётся и загружается  сразу после загрузки и инициализации  гипервизора. Этот домен имеет особые права на управление гипервизором и по умолчанию всё аппаратное обеспечение компьютера доступно из dom0. Фактически, dom0 — это место жизни ПО, управляющего Xen . dom0 всегда один.

domU — рядовой домен  (сокращение от User domain), содержащий в себе домен выполняющихся виртуальных машин. Обычно не имеет доступа к реальному оборудованию и является «полезной нагрузкой» системы виртуализации. В отличие от dom0, domU может быть множество (обычно несколько десятков).

stub-domain — домен, в котором запущена очень специализированная ОС, обеспечивающая работу с каким-либо оборудованием или бэк-эндом драйвера. Является развитием модели безопасности Xen. В продакте (то есть в промышленно применяемых системах виртуализации на базе Xen) пока не используется.

domain builder (конструктор  доменов) — программа, которая  создаёт domU (загружает в него  нужный код и сообщает гипервизору  о необходимости запуска). Помимо  конструирования домена, обычно  занимается подключением и конфигурированием  виртуальных устройств, доступных для виртуальной машины. Она же отвечает за процесс миграции виртуальной машины с хоста на хост.

 
 

Аппаратная виртуализация

Основная статья: Аппаратная виртуализация

В режиме аппаратной виртуализации (HVM) гостевая ОС не «знает»  про существование гипервизора. Xen с помощью модулей из QEMU эмулирует реальное аппаратное обеспечение и позволяет провести начальную загрузку ОС. По её окончании для нормальной производительности должны запускаться PV-драйверы, которые реализуют быстрый интерфейс с виртуальными устройствами, подобно тому, как это работает в PV-режиме). Поскольку большинство привилегированных операций эмулируется, возможен запуск Xen в HVM-режиме из-под Xen. В этом случае вложенный гипервизор сможет работать только в PV-режиме.

 

Минимизация функций  гипервизора

Гипервизор Xen (по состоянию  на версии 3 и 4) реализует минимальный  набор операций для управления оперативной  памятью, состоянием процессора, таймерами  реального времени и счётчиками тактов (TSC) процессора, прерываниями и контролем за DMA. Все остальные функции, такие как реализация дисковых и блочных устройств, создание и удаление виртуальных машин, их миграция между серверами и т. д. реализуется в управляющем домене. За счёт этого размер гипервизора получается весьма малым (для версии 3.4 размер двоичного кода всего гипервизора меньше 600 КБ), так же как и размер его исходного текста. По замыслу авторов это увеличивает устойчивость системы виртуализации, так как ошибка в компонентах вне гипервизора не приводит к компрометации/повреждению самого гипервизора и ограничивает повреждения только вышедшей из строя компонентой, не мешая работать остальным.

Все функции, связанные  с обеспечением работы сети, блочных (дисковых) устройств, эмуляции видеоадаптеров и прочих устройств вынесены за пределы гипервизора. Большинство таких устройств состоит из двух частей: драйвера в domU и программы в dom0. Драйвер (чаще всего встроенный в ядро ОС или загружающийся в виде модуля) реализует минимальный объём работы, фактически, транслируя запросы от ОС в программу в dom0. Программа в dom0 выполняет основную часть работы. При этом программа чаще всего запускается в виде отдельного процесса для каждого обслуживаемого устройства. Сбой в такой программе ведёт к сбою только одного устройства (блочного, сетевого) и не затрагивает работу других копий программы (то есть не затрагивает сетевые/блочные устройства остальных доменов, или даже другие устройства того же самого домена).

Традиционно используется следующая терминология: front — часть  модуля, находящегося в domU, back — часть, находящаяся в dom0. Для некоторых типов устройств «задняя» часть может быть различной при сохранении одной и той же «передней» части. Например, драйвер блочного устройства может иметь backend в форме программы работы с VHD-образами, с блочными устройствами, с iscsi-инициатором и т. д.

 

Междоменное взаимодействие

Xen предоставляет  доменам три механизма взаимодействия: один — с гипервизором (hypercalls), и два между доменами. Чаще  всего, взаимодействие происходит  между dom0 и domU, хотя модель допускает взаимодействие и между двумя domU.

Междоменное взаимодействие сводится к двум видам: events (события) и shard mem (общий доступ к памяти). Третий вариант — передача страницы памяти, является частным случаем общего доступа к памяти.

Events служат примерно  для того же, для чего служат  прерывания в архитектуре x86 или  сигналы в Unix — быстрая синхронная  или асинхронная передача сигнала  о наступлении какого-то события.  Общий доступ к памяти обеспечивает  возможность передачи значительных объемов информации, а события — скорость передачи.

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

 

Toolstack

 

В связи с тем, что  сам гипервизор (около 500—600 КБ) реализует только «ядро» системы, весь остальной функционал выносится на прикладной уровень, работающий в dom0. Набор программ, реализующий функциональность за пределами Xen называют англ. toolstack (устоявшегося перевода не имеется).

Существуют две версии toolstack для Xen: основанная на xend (входит в большинство поставок Xen) и основанная на xapi (входит в состав Xen Cloud Platform). Xend развивался одновременного с Xen, написан на Python и с самого начала шёл под открытой лицензией. Xapi был проприетарной разработкой Xensource (в дальнейшем Citrix), но в 2009 году был опубликовано под лицензией GPL. Xapi написано на OCaml, имеет меньший набор возможностей, но работает более стабильно.

В обеих версиях toolstack присутствуют следующие утилиты:

xenstored — демон, реализующий интерфейс XenStore. В xapi-toolstack он переписан на ocaml, но реализует ту же самую функциональность.

xenconsoled — демон,  обеспечивающий в dom0 доступ к  консолям виртуальных машин. Xenconsoled реализует бэкэнд консольного  устройства для domU и использует API unix98 для создания псевдотерминалов в dom0. Соответствие между номером псевдотерминала и виртуальной машиной записывается в XenStore.