close

Вход

Забыли?

вход по аккаунту

?

Синхронизация облачных процессов.

код для вставкиСкачать
НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «IN SITU» №3/2015 ISSN 2411-7161
пользователя может быть использован автоматический метод классификации или полуавтоматический с
участием оператора.
Список использованной литературы:
1. Martinsky O. Algorithmic and mathematical principles of automatic number plate recognition systems // Brno
University of technology, 2007, pp.83
2. Методы компьютерной обработки изображений / В.А. Сойфер [и др.]. М.: Физматлит, 2003. 784 с.
3. Гонсалес Р., Вудс Р. Цифровая обработка изображений. М.:Техносфера, 2006. 1072 с.
© Моренов С.В., 2015
Петрова Светлана Юрьевна
канд. техн. наук, доцент НовГУ,
г.В.Новгород, РФ
Е-mail: Svetlana.petrova@novsu.ru
СИНХРОНИЗАЦИЯ ОБЛАЧНЫХ ПРОЦЕССОВ
Аннотация
В последние десятилетия закрепилась идея, что более эффективная обработка информации может быть
произведена централизованно, с помощью облачных вычислительных систем и хранилищ, доступных через
Интернет. Облачные вычисления наследует некоторые из проблем параллельных и распределенных систем,
в частности синхронизация групповых процессов. Описывается проблематика реализации глобальных часов,
синхронизирующих процессы в облачных сервисах.
Ключевые слова
Облачные технологии, большие данные, состояние системы
Облачная обработка данных базируется на большом количестве накопленных идей и опыте, которые
были получены в результате разработки суперкомпьютеров, и вычислительных систем, базирующихся на
гарвардской архитектуре. Облачные технологи тесно связаны с параллельными и распределенными
компьютерными вычислениями.
В основе облачных приложений лежит клиент-серверная парадигма с относительно простым
программным обеспечением для тонких клиентов, работающих на компьютере пользователя, и мощным
компьютерным обеспечением на облачных серверах. Отличие от обычной клиент-серверной архитектуры
заключается в том, что вычислительный запрос одного клиента может обрабатываться сразу несколькими
серверами.
В самом простом виде эта операция может выглядеть следующим образом:
1) пользователь со своего локального компьютера через сеть запрашивает данные или службы на
удаленном хосте;
2) удаленный хост обрабатывает запрос и отправляет данные или результаты запроса обратно на
локальный хост;
3) локальный компьютер передает ответ клиенту, не оповещая клиента о том, что запрос был выполнен
несколькими серверами параллельно.
В такой архитектуре хост-сервер (координатор) дирижирует распределенными вычислениями одно
ранговых серверных узлов, а не делает все самостоятельно. Важно отметить, что любой хост-сервер может
выступать в качестве координатора, в зависимости от того, в каком месте сети возник запрос на обработку
данных.
35
НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «IN SITU» №3/2015 ISSN 2411-7161
Многие облачные приложения обрабатывают большие объемы данных, поэтому используют
несколько параллельно работающих экземпляров. Но такая организация обработки данных вызывает
потенциальные проблемы, связанные с параллелизмом. Например, когда два или более процессов, или
потоков постоянно меняют свое состояние в ответ на изменения в других процессах, мы имеем условие
динамического блокирования, в результате ни один из процессов не может завершить свое выполнение.
Очень часто процессам/потокам, работающим одновременно, назначены приоритеты и выполнение
планируется на основе этих приоритетов. Инверсия приоритетов происходит, когда процесс или задача с
более высоким приоритетом косвенно вытеснена процессом с более низким приоритетом.
Преимущества таких систем очевидны, вот некоторые из них: 1) размещение данных ближе к
источнику; 2) автоматическое перемещение ресурсов туда, где они наиболее необходимы; 3) размещение
данных ближе к пользователям (через репликацию); 4) максимальная доступность данных через репликацию
данных; 5) высокая отказоустойчивость за счет исключения единой точки отказа; 6) потенциально более
эффективный доступ к данным (более высокая пропускная способность и больший потенциал для
обеспечения параллелизма); 7) улучшение масштабируемости приложений.
Для понимания важных свойств облачных систем используется абстрактная модель, базирующаяся на
двух важных компонентах: процессы и каналы связи. Процессом, по существу, называют программу в
момент выполнения. В настоящее время в большинстве операционных систем определены два типа единиц
работ: более крупная единица работы, обычно называется процессом, или задачей, которая требует для
своего выполнения нескольких более мелких работ, для обозначения которых используют термины поток
или нить. Процесс характеризуется его состоянием; состояние является совокупностью информации,
которая нужна, чтобы перезапустить процесс после того, как он был приостановлен.
Обнаружение параллелизма часто бывает сложной задачей и развитие параллельных алгоритмов
требует значительных усилий. Например, многие проблемы численного анализа, такие как решения больших
систем линейных уравнений или решения систем дифференциальных уравнений в частных, требует
алгоритмы, основанные на методах декомпозиции домена. Чтобы решить систему дифференциальных
уравнений в частных производных над областью D параллельный алгоритм может разделять данные на
несколько сегментов и назначает каждый сегмент одному из членов группы процессов. Процессы в группе
должны сотрудничать друг с другом и повторяются до тех пор, пока общие граничные значения,
вычисленные по одному процессу, не согласуются с общими граничными значениями, вычисленными по
другому процессу. Канал связи предоставляет средства коммуникации для процессов.
Состояние канала связи определяется следующим образом: рассматривая два процесса  и  ,
состояние канала ξi,j, от  к  состоит из сообщений, отправленных  , но еще не полученных процессом
 .

Событие является изменением состояния процесса. Процесс  находится в состояние  сразу после
возникновения события  и остается в этом состоянии до наступления следующего события +1 .
Глобальные состояния в облачных вычислениях с n процессами образуют n –мерную решетку.
Предположим ℎ это история процесса  вплоть до его j -ого события  , и предположим  это
локальное состояние процесса  следующего события  .
Если рассматривать систему состоящую из n процессов 1 , 2 , … ,  , … ,  , где  – локальное
состояние процесса  , тогда глобальное состояние системы является кортежем из n элементов локальных
состояний
Σ(1 ,2 ,…,) = (11 , 22 , … ,  , … ,  )
Для достижения глобального состояния системы в случае двух потоков количество
коммуникационных путей из начального состояния Σ(0,0) в состояние Σ(m,n) определяется формулой:
N (m,n) = (m + n) /(m!n!)
Чем больше коммуникационных путей, тем сложнее определить события, ведущие к данному
состоянию.
36
НАУЧНОЕ ПЕРИОДИЧЕСКОЕ ИЗДАНИЕ «IN SITU» №3/2015 ISSN 2411-7161
Процесс, ответственный за построение глобального состояния системы называется монитором.
Монитор отправляет сообщения, запрашивающие информацию о локальных состояниях каждого процесса,
и собирает ответы для построения глобального состояния. Построение глобального состояния эквивалентно
созданию моментальных снимков отдельных процессов, которые затем объединены в глобальное
представление о состоянии системы в целом. Объединение моментальных снимков, это несложный процесс,
если снимки всех процессов сделаны в одно и то же время глобальных часов.
Глобальные часы необходимы для инициирования параллельных процессов. В отсутствие глобальных
часов, обеспечить условия синхронизации процессов можно только используя следующую абстракцию –
логические часы ℒ() события e.
Каждая временная метка процесса для каждого отправленного сообщения m со значением логических
часов на время отправки [1, с. 34],
() = ℒ(()).
ℒ + 1 если  это локальное событие, или событие  = ()
ℒ () = {
max(ℒ +  ( ) + 1) если событие  = ().
Каждый процесс маркирует локальное событие и отправляет события последовательно, пока не
получит сообщение, отмеченное значением логических часов, которое больше, чем следующее значение
локальных логических часов.
К сожалению, логические часы не могут установить глобальный порядок всех событий, тем не менее,
коммуникационные события позволяют различным процессам скоординировать свои логические часы. Для
этого можно использовать причинно-следственную доставку сообщений, группировку моментальных
снимков локальный систем, а также протоколы Chandy и Lamport.
Список использованной литературы:
1. Dan C. Marinescu. Cloud Computing. Theory and Practice. Morgan Kaufmann. 2013. – 415 pp.
2. Mitch Tulloch, Symon Perriman. Introducing Microsoft System Center 2012 R2 Technical Overview. Microsoft
Press, 2013. – 180 pp.
3. Rajkumar Buyya, Christian Vecchiola, S. Thamarai Selvi. Mastering Cloud Computing Foundations and
Applications Programming. Morgan Kaufmann, 2013. – 469 pp.
4. Rajkumar Buyya, James Broberg, Andrzej Goscinski. Cloud computing Principles and Paradigms. Published by
John Wiley & Sons, Inc. 2011. – 647 pp.
© Петрова С.Ю., 2015
Савашинский Илья Игоревич
УРФУ, ИРИТ-РтФ, каф. РТС, студ. 4 курс
г. Екатеринбург, РФ
egor37-ilya14@yandex.ru
Бекетова Анна Павловна (научн. руковод.)
УРФУ, каф. ин. языков и перевода ИнФО, ст. препод.
г. Екатеринбург, РФ
annishuara@ya.ru
INITIAL ESTIMATION OF INFORMATION DAMAGE CAUSED TO RADIO-LOCATING SYSTEMS
BY RADIO-ELECTRONIC WARFARE DEVICES
Аннотация
В данной работе проведена первоначальная оценка информационного ущерба, наносимого
радиолокационным системам (РЛС) средствами радиоэлектронной борьбы на основе создания активных
37
Документ
Категория
Без категории
Просмотров
19
Размер файла
968 Кб
Теги
процессов, синхронизация, облачные
1/--страниц
Пожаловаться на содержимое документа