Репликация (вычисления)

Репликация в вычислениях предполагает обмен информацией для обеспечения согласованности между избыточными ресурсами, такими как программные или аппаратные компоненты, для повышения надежности, отказоустойчивости или доступности.

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

Репликация в вычислениях может означать:

Репликация данных , когда одни и те же данные хранятся на нескольких устройствах хранения.
Репликация вычислений , при которой одна и та же вычислительная задача выполняется много раз. Вычислительные задачи могут быть:
- Реплицируется в космосе , где задачи выполняются на отдельных устройствах.
- Реплицируется во времени , когда задачи выполняются неоднократно на одном устройстве.

Репликация в пространстве или во времени часто связана с алгоритмами планирования. ^[1]

Доступ к реплицируемому объекту обычно аналогичен доступу к одному нереплицируемому объекту. Сама репликация должна быть прозрачной для внешнего пользователя. В случае сбоя переключение реплик должно быть максимально скрыто с точки зрения качества обслуживания . ^[2]

Ученые-компьютерщики далее описывают репликацию как:

Активная репликация , которая выполняется путем обработки одного и того же запроса на каждой реплике.
Пассивная репликация , которая включает обработку каждого запроса на одной реплике и передачу результата на другие реплики.

Когда одна ведущая реплика назначается путем выбора лидера для обработки всех запросов, система использует схему первичного резервного копирования или первичной реплики , которая преобладает в кластерах высокой доступности . Для сравнения, если какая-либо реплика может обрабатывать запрос и распространять новое состояние, система использует схему с несколькими первичными или несколькими главными узлами . В последнем случае необходимо использовать некоторую форму управления распределенным параллелизмом , например распределенный менеджер блокировок .

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

Резервное копирование отличается от репликации тем, что сохраненная копия данных остается неизменной в течение длительного периода времени. ^[3] Реплики же подвергаются частым обновлениям и быстро теряют историческое состояние. Репликация — одна из старейших и наиболее важных тем в области распределенных систем .

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

Модели репликации в распределенных системах

Существуют три широко цитируемые модели репликации данных, каждая из которых имеет свои свойства и производительность:

Репликация транзакций : используется для репликации транзакционных данных , таких как база данных. Используется модель сериализуемости с одной копией , которая определяет действительные результаты транзакции с реплицируемыми данными в соответствии с общими свойствами ACID (атомарность, согласованность, изоляция, долговечность), которые транзакционные системы стремятся гарантировать.
Репликация конечного автомата : предполагает, что реплицируемый процесс представляет собой детерминированный конечный автомат и что атомарная трансляция возможна каждого события. Он основан на распределенном консенсусе и имеет много общего с моделью репликации транзакций. Иногда это ошибочно используют как синоним активной репликации. Репликация конечного автомата обычно реализуется посредством реплицируемого журнала, состоящего из нескольких последовательных раундов алгоритма Paxos . Это было популяризировано системой Google Chubby и является основой хранилища данных Keyspace с открытым исходным кодом . ^[4]^[5]
Виртуальная синхрония : включает группу процессов, которые взаимодействуют для репликации данных в памяти или координации действий. Модель определяет распределенную сущность, называемую группой процессов . Процесс может присоединиться к группе, и ему предоставляется контрольная точка, содержащая текущее состояние данных, реплицируемых членами группы. Затем процессы смогут отправлять многоадресные рассылки группе и будут видеть входящие многоадресные рассылки в том же порядке. Изменения членства обрабатываются как специальная многоадресная рассылка, которая предоставляет новое «представление членства» процессам в группе. ^[6]

Репликация базы данных

Репликация базы данных может использоваться во многих системах управления базами данных (СУБД), обычно с отношениями первичный/реплика между оригиналом и копиями. Первичный сервер регистрирует обновления, которые затем передаются на реплики. Каждая реплика выводит сообщение об успешном получении обновления, что позволяет отправлять последующие обновления.

При репликации с несколькими хозяевами обновления могут отправляться на любой узел базы данных, а затем распространяться на другие серверы. Это часто желательно, но влечет за собой существенное увеличение затрат и сложности, что в некоторых ситуациях может сделать это непрактичным. Наиболее распространенной проблемой, возникающей при репликации с несколькими хозяевами, является предотвращение или разрешение транзакционных конфликтов . Большинство решений синхронной (или активной) репликации выполняют предотвращение конфликтов, тогда как асинхронные (или ленивые) решения должны выполнять разрешение конфликтов. Например, если одна и та же запись изменяется на двух узлах одновременно, активная система репликации обнаружит конфликт перед подтверждением фиксации и прервет одну из транзакций. Система ленивой репликации позволит обеим транзакциям фиксировать и запускать разрешение конфликтов во время повторной синхронизации. ^[7] Разрешение такого конфликта может быть основано на временной метке транзакции, на иерархии исходных узлов или на гораздо более сложной логике, которая принимает решения последовательно для всех узлов.

и вертикальном масштабировании Репликация базы данных становится более сложной при горизонтальном . При горизонтальном масштабировании имеется больше реплик данных, тогда как при вертикальном масштабировании реплики данных располагаются на больших физических расстояниях. Проблемы, возникающие при горизонтальном масштабировании, можно решить с помощью многоуровневого протокола доступа с несколькими представлениями . Первые проблемы вертикального расширения в основном решались за счет повышения надежности и производительности Интернета. ^[8]^[9]

Когда данные реплицируются между серверами баз данных, так что информация остается согласованной во всей системе базы данных, и пользователи не могут сказать или даже узнать, какой сервер в СУБД они используют, говорят, что система демонстрирует прозрачность репликации.

Однако прозрачность репликации не всегда может быть достигнута. Когда данные реплицируются в базе данных, они будут ограничены теоремой CAP или теоремой PACELC . В движении NoSQL согласованностью данных обычно жертвуют в обмен на другие, более желательные свойства, такие как доступность (A), устойчивость к разделению (P) и т. д. Также были разработаны различные модели согласованности данных , которые служат соглашением об уровне обслуживания (SLA). между поставщиками услуг и пользователями.

Репликация дискового хранилища

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

Самый простой метод — зеркалирование диска , типичное для локально подключенных дисков. В сфере хранения данных определения сужаются, поэтому зеркалирование является локальной (на небольшом расстоянии) операцией. Репликацию можно расширить по компьютерной сети , так что диски могут быть расположены в физически удаленных местах, и обычно применяется модель репликации базы данных «основная/реплика». Цель репликации — предотвратить ущерб от сбоев или катастроф , которые могут произойти в одном месте, или, в случае возникновения таких событий, улучшить возможность восстановления данных. Для репликации задержка является ключевым фактором, поскольку она определяет либо расстояние между сайтами, либо тип репликации, который можно использовать.

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

Синхронная репликация гарантирует «нулевую потерю данных» посредством операций атомарной записи, при которых операция записи не считается завершенной до тех пор, пока не будет подтверждена как локальным, так и удаленным хранилищем. Большинство приложений ждут завершения транзакции записи, прежде чем продолжить дальнейшую работу, поэтому общая производительность значительно снижается. По сути, производительность падает пропорционально расстоянию, поскольку минимальная задержка определяется скоростью света . На расстоянии 10 км максимально быстрый путь туда и обратно занимает 67 мкс, тогда как вся запись в локальный кэш завершается примерно за 10–20 мкс.

При асинхронной репликации операция записи считается завершенной, как только локальное хранилище подтверждает ее. Удаленное хранилище обновляется с небольшой задержкой . Производительность значительно увеличивается, но в случае сбоя локального хранилища в удаленном хранилище не гарантируется наличие текущей копии данных (самые последние данные могут быть потеряны).

Полусинхронная репликация обычно считает операцию записи завершенной, когда она подтверждена локальным хранилищем и получена или зарегистрирована удаленным сервером. Фактическая удаленная запись выполняется асинхронно, что приводит к повышению производительности, но удаленное хранилище будет отставать от локального хранилища, поэтому нет никакой гарантии надежности (т. е. прозрачности) в случае сбоя локального хранилища. ^{[ нужна ссылка ]}

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

Реализации

Многие распределенные файловые системы используют репликацию, чтобы обеспечить отказоустойчивость и избежать единой точки отказа.

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

Методы оптимизации глобальной сети (WAN) могут применяться для устранения ограничений, налагаемых задержкой.

Репликация на основе файлов

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

Захват с помощью драйвера ядра

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

Решения репликации на уровне файлов позволяют принимать обоснованные решения о репликации на основе местоположения и типа файла. Например, могут быть исключены временные файлы или части файловой системы, не имеющие коммерческой ценности. Передаваемые данные также могут быть более детальными; если приложение записывает 100 байт, передаются только 100 байт вместо полного блока диска (обычно 4096 байт). Это существенно уменьшает объем данных, отправляемых с исходного компьютера, и нагрузку на хранилище на целевом компьютере.

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

Репликация журнала файловой системы

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

Одной из примечательных реализаций является Microsoft System Center Data Protection Manager (DPM), выпущенный в 2005 году, который выполняет периодические обновления, но не обеспечивает репликацию в реальном времени. ^{[ нужна ссылка ]}

Пакетная репликация

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

Одной из примечательных реализаций является rsync .

Репликация внутри файла

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

В системе IBM от VSAM индексные данные иногда реплицируются внутри дорожки, чтобы уменьшить задержку вращения.

Репликация распределенной общей памяти

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

Первичное резервное копирование и мультиосновная репликация

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

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

Ученый-компьютерщик Джим Грей проанализировал схемы многократной первичной репликации в рамках транзакционной модели и опубликовал широко цитируемую статью, в которой скептически относится к этому подходу «Опасности репликации и решение». ^[10]^[11] Он утверждал, что, если данные не будут разделены каким-то естественным образом, так что базу данных можно будет рассматривать как n $n$ непересекающихся подбаз данных, конфликты управления параллелизмом приведут к серьезному снижению производительности, и группа реплик, вероятно, будет замедляться как функция n . Грей предположил, что наиболее распространенные подходы, вероятно, приведут к деградации, масштабируемой как O(n³) . Его решение, заключающееся в секционировании данных, жизнеспособно только в ситуациях, когда данные действительно имеют естественный ключ секционирования.

В 1985–1987 годах модель виртуальной синхронизации была предложена и стала широко распространенным стандартом (она использовалась в системах Isis Toolkit, Horus, Transis, Ensemble, Totem, Spread , C-Ensemble, Phoenix и Quicksilver и является основу для CORBA стандарта отказоустойчивых вычислений ). Виртуальная синхронизация допускает многоосновной подход, при котором группа процессов взаимодействует для распараллеливания некоторых аспектов обработки запросов. Эту схему можно использовать только для некоторых форм данных в памяти, но она может обеспечить линейное увеличение размера группы.

Ряд современных продуктов поддерживают подобные схемы. Например, Spread Toolkit поддерживает ту же самую модель виртуальной синхронизации и может использоваться для реализации схемы репликации с несколькими первичными узлами; таким же образом можно было бы использовать C-Ensemble или Quicksilver. WANdisco допускает активную репликацию, при которой каждый узел в сети является точной копией или репликой и, следовательно, каждый узел в сети активен одновременно; эта схема оптимизирована для использования в глобальной сети (WAN).

Современные протоколы мультипервичной репликации оптимизируют общую безотказную работу. Цепная репликация ^[12] — популярное семейство таких протоколов. Современные варианты протокола ^[13] Цепная репликация обеспечивает высокую пропускную способность и надежную согласованность за счет объединения реплик в цепочку для записи. Этот подход обеспечивает локальное чтение на всех узлах реплики, но имеет высокую задержку при записи, которая должна проходить через несколько узлов последовательно.

Более поздний многоосновной протокол Hermes . ^[14] сочетает в себе аннулирование на основе когерентного кэша и логические временные метки для достижения строгой согласованности с локальным чтением и высокопроизводительной записью со всех реплик. Во время безошибочной работы его широковещательные записи не конфликтуют и фиксируются после всего лишь одного многоадресного обращения к узлам реплики. Такая конструкция обеспечивает высокую пропускную способность и низкую задержку как при чтении, так и при записи.

См. также

Ссылки

^ Мансури, Наджме, Голам, Хосейн Дастгайбифард и Эхсан Мансури. «Сочетание алгоритма репликации данных и планирования для повышения доступности данных в сетях данных», Журнал сетевых и компьютерных приложений (2013).
^ В. Андронику, К. Мамурас, К. Церпес, Д. Кириазис, Т. Варваригу, «Динамическая репликация данных с учетом QoS в грид-средах», Elsevier Future Generation Computer Systems - Международный журнал грид-вычислений и электронной науки , 2012 г.
^ «Резервное копирование и репликация: в чем разница?» . Зерто . 6 февраля 2012 г.
^ Мартон Тренчени, Аттила Газсо (2009). «Пространство ключей: последовательно реплицируемое, высокодоступное хранилище значений ключей» . Проверено 18 апреля 2010 г.
^ Майк Берроуз (2006). «Служба Chubby Lock для слабосвязанных распределенных систем» . Архивировано из оригинала 9 февраля 2010 г. Проверено 18 апреля 2010 г.
^ Бирман, К.; Джозеф, Т. (1 ноября 1987 г.). «Использование виртуальной синхронизации в распределенных системах» . Материалы одиннадцатого симпозиума ACM по принципам операционных систем - SOSP '87 . СОСП '87. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 123–138. дои : 10.1145/41457.37515 . ISBN 978-0-89791-242-6 . S2CID 7739589 .
^ «Репликация — разрешение конфликтов» . Руководство пользователя ITTIA DB SQL™ . ООО «ИТТИА» Архивировано из оригинала 24 ноября 2018 года . Проверено 21 октября 2016 г.
^ Драган Симич; Сречко Ристич; Слободан Обрадович (апрель 2007 г.). «Измерение достигнутого уровня производительности веб-приложений с распределенной реляционной базой данных» (PDF) . Электроника и энергетика . Факта Университета. п. 31–43 . Проверено 30 января 2014 г.
^ Мокадем Риад; Хамерлен Абделькадер (декабрь 2014 г.). «Стратегии репликации данных с целью повышения производительности в системах Grid данных: обзор» (PDF) . Внутренний журнал сетевых и коммунальных вычислений . Издательство Underscience. п. 30–46 . Проверено 18 декабря 2014 г.
^ «Опасности репликации и решение»
^ Материалы Международной конференции ACM SIGMOD 1999 г. по управлению данными: SIGMOD '99 , Филадельфия, Пенсильвания, США; 1–3 июня 1999 г., том 28; п. 3.
^ ван Ренесс, Робберт; Шнайдер, Фред Б. (6 декабря 2004 г.). «Цепная репликация для поддержки высокой пропускной способности и доступности» . Материалы 6-й конференции симпозиума по проектированию и внедрению операционных систем - Том 6 . ОСДИ'04. США: Ассоциация USENIX: 7.
^ Террас, Джефф; Фридман, Майкл Дж. (14 июня 2009 г.). «Объектное хранилище на CRAQ: высокопроизводительная цепная репликация для рабочих нагрузок, ориентированных преимущественно на чтение» . Ежегодная техническая конференция USENIX . USENIX'09. США: 11.
^ Кацаракис, Антониос; Гавриелатос, Василис; Катебзаде, г-н Сиаваш; Джоши, Арпит; Драгоевич, Александр; Грот, Борис; Нагараджан, Виджай (13 марта 2020 г.). «Гермес: быстрый, отказоустойчивый и линеаризуемый протокол репликации» . Материалы двадцать пятой международной конференции по архитектурной поддержке языков программирования и операционных систем . АСПЛОС '20. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 201–217. дои : 10.1145/3373376.3378496 . hdl : 20.500.11820/c8bd74e1-5612-4b81-87fe-175c1823d693 . ISBN 978-1-4503-7102-5 . S2CID 210921224 .

[1] Мансури, Наджме, Голам, Хосейн Дастгайбифард и Эхсан Мансури. «Сочетание алгоритма репликации данных и планирования для повышения доступности данных в сетях данных», Журнал сетевых и компьютерных приложений (2013).

[2] В. Андронику, К. Мамурас, К. Церпес, Д. Кириазис, Т. Варваригу, «Динамическая репликация данных с учетом QoS в грид-средах», Elsevier Future Generation Computer Systems - Международный журнал грид-вычислений и электронной науки , 2012 г.

[3] «Резервное копирование и репликация: в чем разница?» . Зерто . 6 февраля 2012 г.

[keyspace-4] Мартон Тренчени, Аттила Газсо (2009). «Пространство ключей: последовательно реплицируемое, высокодоступное хранилище значений ключей» . Проверено 18 апреля 2010 г.

[chubby-5] Майк Берроуз (2006). «Служба Chubby Lock для слабосвязанных распределенных систем» . Архивировано из оригинала 9 февраля 2010 г. Проверено 18 апреля 2010 г.

[6] Бирман, К.; Джозеф, Т. (1 ноября 1987 г.). «Использование виртуальной синхронизации в распределенных системах» . Материалы одиннадцатого симпозиума ACM по принципам операционных систем - SOSP '87 . СОСП '87. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 123–138. дои : 10.1145/41457.37515 . ISBN 978-0-89791-242-6 . S2CID 7739589 .

[7] «Репликация — разрешение конфликтов» . Руководство пользователя ITTIA DB SQL™ . ООО «ИТТИА» Архивировано из оригинала 24 ноября 2018 года . Проверено 21 октября 2016 г.

[8] Драган Симич; Сречко Ристич; Слободан Обрадович (апрель 2007 г.). «Измерение достигнутого уровня производительности веб-приложений с распределенной реляционной базой данных» (PDF) . Электроника и энергетика . Факта Университета. п. 31–43 . Проверено 30 января 2014 г.

[9] Мокадем Риад; Хамерлен Абделькадер (декабрь 2014 г.). «Стратегии репликации данных с целью повышения производительности в системах Grid данных: обзор» (PDF) . Внутренний журнал сетевых и коммунальных вычислений . Издательство Underscience. п. 30–46 . Проверено 18 декабря 2014 г.

[10] «Опасности репликации и решение»

[11] Материалы Международной конференции ACM SIGMOD 1999 г. по управлению данными: SIGMOD '99 , Филадельфия, Пенсильвания, США; 1–3 июня 1999 г., том 28; п. 3.

[12] ван Ренесс, Робберт; Шнайдер, Фред Б. (6 декабря 2004 г.). «Цепная репликация для поддержки высокой пропускной способности и доступности» . Материалы 6-й конференции симпозиума по проектированию и внедрению операционных систем - Том 6 . ОСДИ'04. США: Ассоциация USENIX: 7.

[13] Террас, Джефф; Фридман, Майкл Дж. (14 июня 2009 г.). «Объектное хранилище на CRAQ: высокопроизводительная цепная репликация для рабочих нагрузок, ориентированных преимущественно на чтение» . Ежегодная техническая конференция USENIX . USENIX'09. США: 11.

[14] Кацаракис, Антониос; Гавриелатос, Василис; Катебзаде, г-н Сиаваш; Джоши, Арпит; Драгоевич, Александр; Грот, Борис; Нагараджан, Виджай (13 марта 2020 г.). «Гермес: быстрый, отказоустойчивый и линеаризуемый протокол репликации» . Материалы двадцать пятой международной конференции по архитектурной поддержке языков программирования и операционных систем . АСПЛОС '20. Нью-Йорк, штат Нью-Йорк, США: Ассоциация вычислительной техники. стр. 201–217. дои : 10.1145/3373376.3378496 . hdl : 20.500.11820/c8bd74e1-5612-4b81-87fe-175c1823d693 . ISBN 978-1-4503-7102-5 . S2CID 210921224 .

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]