- •Введение. Система 360
- •Семейство компьютеров
- •Обратная совместимость
- •Наследники и клоны
- •Техническое описание
- •Важные унаследованные особенности
- •Архитектура
- •Операционная система
- •Периферические устройства
- •Устройства хранения с прямым доступом (dasd)
- •Ленточные накопители
- •Линейка мэйнфреймов ibm System/370
- •1. Классическая архитектура «клиент-
- •2. Многоуровневые (многозвенные)
- •2.1. Трехуровневая архитектура.
- •2.2. Менеджеры транзакций
- •3. Архитектура peer to peer
- •2. Понятие и виды кластеров
- •2.1 Отказоустойчивые кластеры
- •2.2 Кластеры с балансировкой нагрузки
- •2.3 Высокопроизводительные кластеры
- •3. Коммуникационной среды для повышения эффективности вычислений
- •4. Классы задач, решаемые кластерами
- •5. Типичные задачи кластерных систем
- •6. Пример вычислительного кластера
- •7. Заключение. Стоит ли использовать кластер
- •Изменения Интернет с появлением xml
- •Перевод с одного языка на другой
- •Edi против xml
- •Подход к распределению данных
- •Список литературы
- •Достоинства веб-служб
- •Список литературы
- •Введение
- •Потребность в технологиях Грид
- •Требования к Grid-архитектуре
- •Описание Grid-архитектуры
- •Fabric: управление локальными ресурсами
- •Connectivity: легкость и безопасность коммуникаций
- •Resource: разделение единичных ресурсов
- •Collective: координация ресурсов
- •Applications: уровень приложений
- •Концепция распределенных grid-вычислений
- •На счет grid
- •Вычислительный grid
- •Заключение
- •Список использованных источников
- •Облачные вычисления
- •SaaS (Software-as-a-service) - по-как-услуга
- •ПреимуществаSaaS
- •Концепция облачных вычислений
- •Классификация облаков
- •Преимущества облаков
- •Открытые решения по организации облачных вычислений
- •Eucalyptus
- •OpenNebula
- •Консолидация данных
- •Существующие подходы к консолидации
- •Архитектура централизованных баз данных
- •Архитектура федеративных баз данных
- •Сравнение федеративного и централизованного подходов
- •Требования к программному обеспечению федеративных баз данных
- •Существующие платформы федеративных баз данных
- •Ibm db2 Information Integrator
- •Этапы построения среды облачных вычислений
- •Этап 1. Анализ существующих ресурсов организации
- •Этап 2. Создание прототипа среды облачных вычислений
- •Этап 3. Развертывание прототипа в полном масштабе
5. Типичные задачи кластерных систем
Сегодня можно говорить о том, что кластерные системы успешно применяются для всех задач суперкомпьютинга - от расчетов для науки и промышленности до управления базами данных. Практически любые приложения, требующие высокопроизводительных вычислений, имеют сейчас параллельные версии, которые позволяют разбивать задачу на фрагменты и обсчитывать ее параллельно на многих узлах кластера. Например, для инженерных расчетов (прочностные расчеты, аэромеханика, гидро- и газодинамика) традиционно применяются так называемые сеточные методы, когда область вычислений разбивается на ячейки, каждая из которых становится отдельной единицей вычислений. Эти ячейки обсчитываются независимо на разных узлах кластера, а для получения общей картины на каждом шаге вычислений происходит обмен данными, распространенными в пограничных областях.
Для практических расчетов (3D-анимация, крэш-тесты, разведка нефтяных и газовых месторождений, прогнозирование погоды) обычно используются кластеры из 10-200 узлов. При этом основная задача - обеспечение эффективной работы кластера с конкретным приложением. Архитектура кластера должна обеспечивать масштабируемость ПО при увеличении количества узлов, т. е. прирост производительности при добавлении новых вычислительных модулей. Для этого важно правильно выбрать конфигурацию кластера в зависимости от профиля обмена данными между экземплярами программы, запущенными на разных узлах. Здесь нужно учитывать общий объем пересылаемых данных, распределение длин сообщений, использование групповых операций и т. п
Сегодня даже те задачи, для решения которых традиционно применялись многопроцессорные системы с общей памятью, такие, как управление крупными базами данных, успешно решаются на кластерах. Появление на рынке таких продуктов, как, например, Oracle RAC (Real Applications Cluster), дало возможность применять кластерные системы в области баз данных, а новая версия СУБД Oracle 10g, построенная на базе GRID-технологий, обеспечивает максимально эффективное использование кластерной архитектуры для решения этих задач.
Видно, что класс задач, решать которые можно используя параллельные алгоритмы довольно широк и крайне важен.
Кластерные решения обладают наилучшим на сегодня соотношением цена/производительность и имеют существенно более низкую совокупную стоимость владения. Это достигается благодаря масштабируемости и использованию стандартных общедоступных компонентов, цена которых постоянно снижается. Два кластерных двухпроцессорных узла в среднем на 35% дешевле, чем один четырехпроцессорный SMP-сервер, причем с ростом количества процессоров преимущество кластерных решений по этому параметру увеличивается. Кроме того, кластерная архитектура обеспечивает великолепную отказоустойчивость системы: при выходе из строя одного или нескольких вычислительных модулей (или узлов) кластер не теряет работоспособности и новые задачи могут быть запущены на меньшем числе узлов. Вышедший из строя узел легко и быстро вынимается из стойки и заменяется новым, который сразу же включается в работу. Это возможно благодаря коммутируемой топологии современных системных сетей, "когда обмен сообщениями между двумя узлами может идти многими путями. В ходе эксплуатации система типа "СКИФ К-1000" предполагает возможный выход из строя не более 2 узлов в год.
Часто можно встретить заблуждение, что только использование суперкомпьютера может само по себе дать прирост производительности. Это не верно. Если ваша задача не имеет внутреннего параллелизма и не адаптирована соответствующим образом, максимум, что вы можете получить от кластера - это запуск на выполнение нескольких экземпляров программы одновременно, работающих с различными начальными данными. Это не ускорит выполнение одной конкретной программы, но позволит сэкономить много времени, если необходимо посчитать множество вариантов за ограниченное время. Можно привести следующую аналогию: один корабль переплывает море за 7 дней, но семь кораблей не смогут переплыть море за день. За то, они смогут перевезти за неделю в 7раз больше груза. Если объемы вашей задачи таковы, что только один прогон на однопроцессорной машине может длиться сутками, неделями и месяцами, то очевидно, следует приложить усилия по адаптации алгоритма. Следует разделить задачу на несколько (по числу процессоров) более мелких подзадач, которые могут выполняться независимо, а в тех местах, где независимое выполнение невозможно, явно вызывать процедуры синхронизации, для обмена данными через сеть. Например, если вы обрабатываете большой массив данных, то разумно будет разделить его на области и распределить их по процессорам, обеспечив равномерную загрузку всего кластера.