Insight IT

Новое поколение MapReduce в Apache Hadoop

Иван Блинков — Sat, 19 Feb 2011 21:23:00 +0300

В большом бизнесе использование нескольких больших кластеров с финансовой точки зрения более эффективно, чем много маленьких. Чем больше машин в кластере, тем большими наборами данных он может оперировать, больше задач могут выполняться одновременно. Реализация MapReduce в Apache Hadoop столкнулась с потолком масштабируемости на уровне около 4000 машин в кластере. Разрабатывается следующее поколение Apaсhe Hadoop MapReduce, в котором появится общий планировщик ресурсов и отдельный мастер для каждой отдельной задач, управляющий выполнением программного кода. Так как простой оборудования по техническим причинам обходится дорого на таком масштабе, высокий уровень доступности проектируется с самого начала, ровно как и безопасность и многозадачность, необходимые для поддержки одновременного использования большого кластера многими пользователями. Новая архитектура также будет более инновационной, гибкой и эффективной с точки зрения использования вычислительных ресурсов.

Предистория

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

Требования

Прежде чем кардинально что-то менять в Hadoop mapreduce, необходимо понять какие же основные требования предъявляются к вычислительным кластерам на практике. Наиболее значительными требованиями к Hadoop следующего поколения являются:

Надежность
Доступность
Масштабируемость - кластеры из как минимум 10 тысяч машин, 200 тысяч вычислительных ядер и даже больше
Обратная и прямая совместимость - возможность быть уверенным, что приложение будет работать на новой версии так же, как оно работало на старой
Контроль над обновлениями
Предсказуемые задержки
Эффективное использование ресурсов

Среди менее значительных требований:

Поддержка альтернативных парадигм разработки (помимо MapReduce)
Поддержка сервисов с коротким жизненным циклом

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

MapReduce следующего поколения

Фундаментальной идеей смены архитектуры является разделение двух основных функций JobTracker'а на два отдельных части:

управление ресурсами;
планирования и мониторинга задач.

В итоге появляется несколько новых ролей:

ResourceManager управляет глобальным распределением вычислительных ресурсов между приложениями;
ApplicationMaster управляет планированием и координацией внутри приложения;
NodeManager управляет процессами в рамках одной машины.

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

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

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

По одному ApplicationMaster запускается для каждого приложения, они ответственны за запрос необходимых ресурсов у планировщика, запуск задач, отслеживание статусов, мониторинг прогресса и обработку сбоев.

Архитектура

Улучшения по сравнению с текущей реализацией MapReduce

Масштабируемость

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

Масштабируемость особенно важна в свете текущих трендов в оборудовании - на данный момент Hadoop может быть развернут на кластере из 4000 машин. Но 4000 средних машин 2009го года (т.е. по 8 ядер, 16Гб памяти, 4Тб дискового пространства) только вдвое менее ресурсоемки, чем 4000 машин 2011го года (16 ядер, 48гб памяти, 24Тб дискового пространства). Помимо этого с точки зрения операционных издержек было выгоднее работать в еще больших кластере от 6000 машин и выше.

Доступность

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

Совместимость протокола

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

Инновационность и гибкость

Основным плюсом предложенной архитектуры является тот факт, что MapReduce по сути становится просто пользовательской библиотекой. Вычислительная же система (ResourceManager и NodeManager) становятся полностью независимыми от специфики MapReduce.

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

Эффективность использования вычислительных ресурсов

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

Таким образом эта схема избавляет от текущего механизма map и reduce слотов в Hadoop, который негативно влияет на эффективную утилизацию вычислительных ресурсов.

Поддержка других парадигм программирования помимо MapReduce

В предложенной архитектуре используется общий механизм вычислений, не привязанный конкретно к MapReduce, что позволит использовать и другие парадигмы. Имеется возможность реализовать собственный ApplicationMaster, способный запрашивать ресурсы у ResourceManager и использовать их в соответствии с задачей, при этом сохраняются общие принципы изоляции и гарантированного наличия полученных ресурсов. Среди потенциально поддерживаемых парадигм можно назвать MapReduce, MPI, Мaster-Worker, итеративные модели. Все они могут одновременно работать на одном и том же кластере. Это особенно актуально для приложений (например К-средний или Page Rank), где другие подходы более чем на порядок эффективнее MapReduce.

Выводы

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

Осталось дело за малым - собственно реализовать задуманное! :)

Источник информации

Подписаться на RSS можно здесь.

Еще раз про HBase

Иван Блинков — Wed, 27 Aug 2008 19:29:00 +0400

Некоторое время назад Neuronus в одном из комментариев к посту "Hadoop возвращается" не согласился с моим кратким определением HBase как "нереляционная база данных" (позаимствованным, собственно говоря, откуда-то с официального портала продукта). Этот факт подтолкнул меня попытаться найти более корректное определение в англоязычных источниках информации, получилось вполне успешно. Хочется прочитать более детально что к чему? Вперед! Если Вам уже приходилось иметь дело с этой системой,возможно Вы уже поняли, что самым сложным этапом работы является просто-напросто осознавание того, чем она на самом деле является. Обычно приходится мысленно отказаться от всех привычек, доставшихся при работе с традиционный RDBMS, и начинать постигать базовые принципы организации хранения данных с нуля.

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

A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

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

map

За этим термином нет четкого устоявшегося обозначения в русском языке (да и в английском тоже все далеко не так однозначно), математики обычно называют это отображением одного множества в другое, в то время как если Вы знакомы с программированием, то Вам наверняка больше знакомы будут более знакомы такие обозначения, как ассоциативный массив (PHP), словарь (Python), хэш (Ruby) или объект (JavaScript).

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

{
  "qqqq" : "some",
  "abc" : "sample",
  "zz" : "JSON",
  "123" : "map",
  "mnbvcxz" : "looks like this"
}

persistent

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

distributed

Распределенность этих систем можно рассматривать с двух точек зрения:

Как HBase, так и BigTable сами по себе могут функционировать на большом количестве серверов, которые можно разделить на две большие категории: master и slave. Slave сервера собственно выполняют всю работу с данными, а master - лишь только координируют их действия и управляют процессом в целом. Этот факт обеспечивают высокую степень устойчивости к сбоям (в HBase правда количество master-серверов ограничено одним, что представляет собой единственную точку, сбой в которой приведет к отказу всей системы, но это лишь временная проблема, которую наверняка устранят в следующих версиях), а также существенно облегчает масштабируемость всей системы так как добавление дополнительных серверов (а значит и увеличение производительности и вместительности системы) достаточно тривиально, безболезненно и не мешает общему ее функционированию.
Помимо этого каждая из этих систем обычно использует для хранения данных кластерную файловую систему (HBase - HDFS, а BigTable - GFS), которые тоже по своей природе являются распределенными и функционируют по схожему принципу, обеспечивая дополнительную сохранность данных, реплицируя их в нескольких экземплярах на нескольких серверах (обычно трех).

sorted

HBase и BigTable не строят никакие индексы для ускорения процесса извлечения данных, единственное используемое в них правило заключается в следующем: каждый slave-сервер в системе отвечает за определенный диапазон ключей (от и до определенных его значений), и держит все записи в строгом лексикографическом порядке по ключам (заметьте: сортировку значений никто не гарантирует!). Продолжая пример с JSON это выглядело бы примерно вот так:

{
  "123" : "map",
  "abc" : "sample",
  "mnbvcxz" : "looks like this",
  "qqqq" : "some",
  "zz" : "JSON"
}

Этим фактом можно активно пользоваться при планировании использовании системы, например если в качестве ключей планируется использовать доменные именные имена, то имеет смысл использовать их в "развернутом" виде, например: "com.example.www" вместо "www.example.com". Это почти наверняка обеспечит попадание всех поддоменов одного и того же домена на один slave-сервер, а также группировку доменов по зонам.

multidimensional

До сих пор ключ интерпретировался нами как нечто единое и неделимое, но на самом деле в данной ситуации это далеко не так. На самом деле пространство имен HBase и BigTable имеет несколько пространств, по аналогии с трехмерным материальным пространством, где есть ширина, высота и глубина. Если мы попытаемся представить это с помощью JSON, то это будет выглядеть как набор вложенных простых map'ов:

{
  "table-1":
  {
     "column-family-1":
     {
        "column-1":
        {
           "row-1":
           {
              "timestamp-1": "value-1",
              "timestamp-2": "value-2",
              "timestamp-3": "value-3"
           },
           "row-2":
           {
              "timestamp-1": "value-4",
              "timestamp-2": "value-5",
              "timestamp-3": "value-6"
           }
        },
        "column-2":
        {
           "row-1":
           {
              "timestamp-1": "value-1",
              "timestamp-3": "value-3"
           },
           "row-2":
           {
              "timestamp-1": "value-4",
              "timestamp-2": "value-5",
              "timestamp-3": "value-6"
           }
        }
     "column-family-2":
     {
        "column-1":
        {
           // ...
        },
        "":
        {
           "row-1": "some-value"
        }
        // ...
     }
     }
  }
}

Как можно увидеть из примера, таких пространств используется пять:

таблицы;
наборы столбцов;
столбцы;
строки;
время;

Таким образом, каждое значение в хранилище данных однозначно соответствует ключу, состоящему из пяти компонентов, например в примере значению "value-5" соответствует ключ, состоящий из:

table-1;
column-family-1;
column-1;
row-2;
timestamp-2;

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

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

sparse

Развивая мысль предыдущего абзаца, можно понять, что наличие значения столбца в каждой строке вовсе не обязательно, оно запросто может и отсутствовать вовсе. Таким образом каждая строка может содержать произвольное количество значений для столбцов в рамках одной column family, ровно как может и не содержать их вовсе. Несуществующие данные не хранятся в виде какого-либо NULL-значения, они просто отсутствуют. Запрос на несуществующие данные просто вернет пустой результат. Если же взглянуть с другой стороны, то тот же самый факт можно представить и как возможность наличия пробелов в списке ключей строк.

И напоследок...

хочется сказать, что все это лишь дело терминологии, ровно то же самое можно подразумевать и под краткой фразой "нереляционная база данных", не смотря на то, что она существенно менее точна и полноценна. В данном контексте самое главное лишь чтобы люди просто понимали друг друга. Надеюсь после прочтения этого поста в вашем сознании сложилась четкая картина этого продукта и предоставляемых им возможностей, которая Вам пригодится как для "общего развития", так и для потенциального практического применения этого продукта. Если остались неясные моменты - смело оставляйте комментарии. Традиционная подписка на RSS - приветствуется :)

GlusterFS

Иван Блинков — Sun, 18 May 2008 21:16:00 +0400

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

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

Список основных ее особенностей по большей части мало чем отличается от других кластерных файловых систем:

Состоит из клиентской и серверной частей. Клиентская часть позволяет монтировать файловую систему, а серверная - glusterfsd - экспортировать в нее локальное дисковое пространство.
Масштабируемость близка к O(1).
Широкий спектр возможностей за счет использования модульной архитектуры.
Имеется возможность восстановления файлов и директорий из файловой системы даже без ее инициализации.
Отсутствие централизованного сервера метаданных, что делает ее более устойчивой к потенциальным сбоям.
Расширяемый интерфейс выполнения задач, с поддержкой загрузки модулей в зависимости от особенностей выполнения пользователями операций по работе с данными.
Расширяющий функциональность механизм трансляторов.
Поддержка Infiniband RDMA и TCP/IP.
Возможность автоматического восстановления в случае сбоев.
Полностью реализована на уровне приложений, что упрощает ее поддержание в рабочем состоянии, портирование и дальнейшую разработку.

Но некоторые моменты все же заслуживают отдельного внимания:

Совместимость

Как уже упоминалось, файловая система реализована полностью на уровне пользовательских приложений, что делает возможным ее монтирование без каких-либо дополнительных патчей в ядре операционной системы, единственное требование к нему: поддержка FUSE. Серверная часть GlusterFS может функционировать на любой POSIX-совместимой операционной системе и протестирована на Linux, FreeBSD, OpenSolaris, в отличии от клиентской части, которая может работать только в Linux.

Модули

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

TCP/IP;
Infiniband-verbs;
Infiniband-SDP.

Балансировка нагрузки может выполняться по следующим алгоритмам:

ALU - использует целый ряд факторов, включающий объем свободного локального дискового пространства, активность операций чтения и записи, количество одновременно открытых файлов, скорость физического вращения дисков. Значимость, придаваемая каждому из показателей, может достаточно гибко настраиваться.
RR - по очереди размещает файлы последовательно на каждом узле, после чего начинает процесс заново, образуя своеобразный цикл. Этот метод эффективен если файлы имеют примерно одинаковый размер, а узлы кластера - одинаковый размер экспортированного локального дискового пространства.
Random - распределяют файлы случайным образом.
NUFA - приоритет отдается созданию файлов локально, а не на других узлах кластера.
Switch - располагает файлы по определенным указанным особенностям имен файлов, по аналогии со switch(filename) в программировании, обычно в качестве критерия распределения файлов имеет смысл использовать их расширение.

Трансляторы: Они представляют собой очень мощный механизм для расширения возможностей GlusterFS, сама идея трансляторов бала позаимствована у GNU/Hurd и заключается она в загрузке бинарных библиотек (.so) в процессе работы системы в зависимости от использованных настроек и использовании их в виде своеобразной цепочки обработчиков при работе с файлами как на серверной, так и на клиентской стороне. В GlusterFS практически все дополнительные возможности реализованы именно виде трансляторов, начиная от дополнений, увеличивающих производительность, заканчивая средствами отладки. Вкратце перечислю основные из них: + AFR - автоматическая репликация файлов. + Stripe - разбивает файлы на блоки фиксированного размера. + Unify - объединяет несколько узлов кластера в один большой виртуальный узел, один узел выделяется для обеспечения внутреннего namespace. Директории создаются на всех узлах, составляющих unify, а каждый файл - лишь на одном (если не используется AFR). + Trace - предоставляют информацию для отладки в виде дополнительных записей в лог. + Filter - фильтрация файлов на основании их имен и/или атрибутов. + Posix-locks - обеспечивает POSIX блокировку записей независимую от используемой системы хранения. + Trash - предоставляет функциональность сопоставимую с libtrash (или "корзиной" - если так понятнее). + Fixed-id - обеспечивает доступ только для пользователей с определенными UID и GUID. + Posix - соединяет GlusterFS с низлежащей локальной файловой системой. + rot-13 - транслятор обеспечивает возможность шифрования и дешифрования данных по примитивному одноименному алгоритму.

Список возможностей, обеспечиваемых широким набором модулей и транслятором, впечатляет, большинство других opensource кластерных файловых систем не могут похвастаться подобной функциональностью (GlusterFS выпускается под GPL). Благодаря возможности работы через Infiniband производительность передачи данных также достаточно высока - она может достигать десятков гигабит в секунду. Обработка сбоев в отдельных узлах также осуществляется достаточно эффективно, так как может быть автоматизирована. Из потенциальных недостатков можно назвать некоторое количество редко проявляющих себя багов в коде, а также достаточно большой размер заголовков в используемом протоколе (несколько сотен байт). В целом эта система вполне работоспособна и полноценно выдерживает конкуренцию со стороны своих opensource "коллег".

Файлы в космосе

Иван Блинков — Sun, 30 Mar 2008 23:06:00 +0400

...или Kosmos Distributed File System

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

Инкрементальная масштабируемость. При добавлении дополнительных узлов в кластер, система сама адаптируется для вовлечения их в полноценную работу.
Стабильный доступ. Реплицируемость данных (по-умолчанию в трех экземплярах) позволяет гарантировать доступность данных вне зависимости от сбоев в работе отдельных узлов.
Балансировка блоков данных. Периодически сервер метаданных перераспределяет данные с целью более оптимального использования дискового пространства.
Целостность данных. Для обеспечения целостности данных вычисляются и сравниваются контрольные суммы блоков данных.
Кэширование. Для увеличения производительности используется кэширования на уровне клиентской библиотеки.
Прозрачная работа с недоступными узлами. Клиентская библиотека прозрачно для приложения переключается на альтернативный сервер с данными, если обнаруживает что один из них недоступен.
Поддержка языков программирования: C++, Java, Python.
Скрипты. С системой предоставляется набор скриптов для развертывания, запуска и остановки узлов.

Но написать этот пост меня подтолкнул вовсе не этот список. В комментариях к одной из предыдущих моих записей читатели подняли тему о целесообразности использования Java для реализации HDFS в частности и Hadoop в целом. В качестве альтернативы был предложен C++ (только на словах конечно же), аргументируя это тем, что такая реализация была бы эффективнее. KFS же как раз и является той самой альтернативой HDFS, написанной на C++. KFS тесно интегрируется с Hadoop с помощью его интерфейсов для файловой системы. Это позволяет Hadoop-приложениям незаметно работать с KFS точно так же, как если бы на ее месте была бы HDFS. Код для интеграции с Hadoop был выпущен в виде патча к Hadoop-JIRA-1963, а начиная с Hadoop версии 0.15 этот код входит в стандартный дистрибутив, ровно как и детальная инструкция по интеграции.

Lustre

Иван Блинков — Fri, 21 Mar 2008 21:53:00 +0300

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

Помимо этого поддерживаются все возможности, который должна иметь любая уважающая себя кластерная файловая система:

поддержка широкого ассортимента типов высокоскоростных сетевых соединений;
надежная система "замков" для обеспечения параллельного доступа к файлам;
возможность автоматического самовосстановления в случае падения любого из узлов;
распределенное управление файловыми объектами для предоставления масштабируемого доступа к файлам.

Изначально архитектура этой файловой системы была разработана просто в рамках исследовательского проекта Петера Браама в 1999, но он решил не останавливаться на достигнутом и основал Cluster File Systems, Inc., в которой уже и велась основная разработка самой файловой системы. Первый релиз Lustre 1.0 был выпущен в 2003 году. Спустя четыре года компания была приобретена Sun Microsystems в октябре 2007 года, но это лишь способствовало дальнейшему развитию проекта. Программное обеспечение, входящее в состав проекта, выпускается под лицензией GPL, что также сыграло немаловажную роль в его жизни.

Архитектура

Каждый компьютер, входящий состав кластера Lustre, выполняет свою четко определенную функцию:

MDS. Сервер метаданных предназначен для хранения всей служебной информации о системе: названия файлов, директорий, прав доступа и так далее. Достаточно наличие одного такого сервера в системе, но для обеспечения надежности на случай каких-либо сбоев, обычно его дублируют. Возможно использование внешнего хранилища данных (MDT), которое может быть общим для двух дублирующих друг друга MDS.
OSS Компьютеры для хранения самих данных. Каждый из них работает с 2-8 OST, в их роли могут выступать практически любые средства хранения данных, начиная от просто жестких дисков или RAID массивов внутри OSS, заканчивая внешними системами хранения данных enterprise-класса. Сумма дискового пространства всех OST и является размером доступного дискового пространства всей файловой системы Lustre.
Клиент. Компьютеры, непосредственно использующие файловую систему. Им предоставляется полный параллельный доступ, полностью соответствующий стандарту POSIX.

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

Возможно более наглядно вышенаписанное сможет представить схема архитектуры системы (позаимствована с официального сайта и переведена):

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

Функционирование

Основным толчком для выполнения каких-либо действий в рамках всей файловой системы обычно является запрос с одного из клиентов. Программное обеспечение для клиентов представляет по сути интерфейс между виртуальной файловой системой Linux и серверами Lustre. Каждому типу серверов соответствует своя часть клиентского ПО: MDC, OSC, MGC. В отличии от Hadoop и GFS файловая система Lustre должна быть примонтирована к локальной системе клиентов для полноценного их функционирования.

Для осуществления коммуникации между клиентами и серверами используется собственный API, известный как LNET. Он поддерживает множество сетевых протоколов с помощью NAL.

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

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

Заключение

Эта файловая система нашла свое применение во множестве крупнейших кластеров и суперкомпьютеров по всему миру, но это не мешает ей с тем же успехом демонстрировать и на кластерах существенно меньшего масштаба. Около половины из самых производительных суперкомпьютеров во всем мире используют Lustre в качестве файловой системы. Помимо этого многие компании предоставляют ее в качестве основы для Linux кластеров (например HP StorageWorks SFS, Cray XT3, Cray XD1). Чем не показатель ее конкурентоспособности?

В качестве источников информации были использованы официальный сайт проекта и иногда страница английской wikipedia.org. На все том же официальном сайте всегда можно найти всю необходимую документацию, а само программное обеспечение проекта доступно на соответствующей странице сайта Sun Mictosystems.

Hadoop

Иван Блинков — Fri, 22 Feb 2008 22:41:00 +0300

Hadoop представляет собой платформу для построения приложений, способных обрабатывать огромные объемы данных. Система основывается на распределенном подходе к вычислениям и хранению информации, основными ее особенностями являются:

Масштабируемость: с помощью Hadoop возможно надежное хранение и обработка огромных объемов данных, которые могут измеряться петабайтами;
Экономичность: информация и вычисления распределяются по кластеру, построенному на самом обыкновенном оборудовании. Такой кластер может состоять из тысяч узлов;
Эффективность: распределение данных позволяет выполнять их обработку параллельно на множестве компьютеров, что существенно ускоряет этот процесс;
Надежность: при хранении данных возможно предоставление избыточности, благодаря хранению нескольких копий. Такой подход позволяет гарантировать отсутствие потерь информации в случае сбоев в работе системы;
Кроссплатформенность: так как основным языком программирования, используемым в этой системе является Java, развернуть ее можно на базе любой операционной системы, имеющей JVM.

HDFS

В основе всей системы лежит распределенная файловая система под незамысловатым названием Hadoop Distributed File System. Представляет она собой вполне стандартную распределенную файловую систему, но все же она обладает рядом особенностей:

Устойчивость к сбоям, разработчики рассматривали сбои в оборудовании скорее как норму, чем как исключение;
Приспособленность к развертке на самом обыкновенном ненадежном оборудовании;
Предоставление высокоскоростного потокового доступа ко всем данным;
Настроена для работы с большими файлами и наборами файлов;
Простая модель работы с данными: один раз записали - много раз прочли;
Следование принципу: переместить вычисления проще, чем переместить данные;

Архитектура HDFS

Проще всего ее демонстрирует схема, позаимствованная с официального сайта проекта и переведенная мной на руский:

Действующие лица:

Namenode: Этот компонент системы осуществляет всю работу с метаданными. Он должен быть запущен только на одном компьютере в кластере. Именно он управляет размещением информации и доступом ко всем данным, расположенным на ресурсах кластера. Сами данные проходят с остальных машин кластера к клиенту мимо него.
Datanode: На всех остальных компьютерах системы работает именно этот компонент. Он располагает сами блоки данных в локальной файловой системе для последующей передачи или обработки их по запросу клиента. Группы узлов данных принято называть Rack, они используются, например, в схемах репликации данных.
Клиент: Просто приложение или пользователь, работающий с файловой системой. В его роли может выступать практически что угодно.

Пространство имен HDFS имеет классическую иерархическую структуру: пользователи и приложения имеют возможность создавать директории и файлы. Файлы хранятся в виде блоков данных произвольной (но одинаковой, за исключением последнего; по-умолчанию 64 mb) длины, размещенных на Datanode'ах. Для обеспечения отказоустойчивости блоки хранятся в нескольких экземплярах на разных узлах, имеется возможность настройки количества копий и алгоритма их распределения по системе. Удаление файлов происходит не сразу, а через какое-то время после соответствующего запроса, так как после получения запроса файл перемещается в директорию /trash и хранится там определенный период времени на случай если пользователь или приложение передумают о своем решении. В этом случае информацию можно будет восстановить, в противном случае - физически удалить.

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

Все коммуникации между компонентами файловой системы проходят по специальным протоколам, основывающимся на стандартном TCP/IP. Клиенты работают с Namenode с помощью так называемого ClientProtocol, а передача данных происходит по DatanodeProtocol, оба они обернуты в Remote Procedure Call (RPC).

Система предоставляет несколько интерфейсов, среди которых командная оболочка DFSShell, набор ПО для администрирования DFSAdmin, а также простой, но эффективный веб-интерфейс. Помимо этого существуют несколько API для языков программирования: Java API, C pipeline, WebDAV и так далее.

MapReduce

Помимо файловой системы, Hadoop включает в себя framework для проведения масштабных вычислений, обрабатывающих огромные объемы данных. Каждое такое вычисление называется Job (задание) и состоит оно, как видно из названия, из двух этапов:

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

Задания выполняются, подобно файловой системе, на всех машинах в кластере (чаще всего одних и тех же). Одна из них выполняет роль управления работой остальных - JobTracker, остальные же ее бесприкословно слушаются - TaskTracker. В задачи JobTracker'а входит составление расписания выполняемых работ, наблюдение за ходом выполнения, и перераспределение в случае возникновения сбоев.

В общем случае каждое приложение, работающее с этим framework'ом, предоставляет методы для осуществления этапов map и reduce, а также указывает расположения входных и выходных данных. После получения этих данных JobTracker распределяет задание между остальными машинами и предоставляет клиенту полную информацию о ходе работ.

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

HBase

В рамках Hadoop доступна еще и система хранения данных, которую правда сложно назвать СУБД в традиционном смысле этого слова. Чаще проводят аналогии с проприетарной системой этого же плана от Google - BigTable.

HBase представляет собой распределенную систему хранения больших объемов данных. Подобно реляционным СУБД данные хранятся в виде таблиц, состоящих из строк и столбцов. И даже для доступа к ним предоставляется язык запросов HQL (как ни странно - Hadoop Query Language), отдаленно напоминающий более распространенный SQL. Помимо этого предоставляется итерирующмй интерфейс для сканирования наборов строк.

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

HQL очень прост по своей сути, если Вы уже знаете SQL, то для изучения его Вам понадобится лишь просмотреть по диагонали коротенький вывод команды help;, занимающий всего пару экранов в консоли. Все те же SELECT, INSERT, UPDATE, DROP и так далее, лишь со слегка измененным синтаксисом.

Помимо обычно командной оболочки HBase Shell, для работы с HBase также предоставлено несколько API для различных языков программирования:

Заключение

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

Архитектура Flickr

Иван Блинков — Fri, 08 Feb 2008 22:41:00 +0300

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

Источники информации

Как и предыдущий пост "Архитектура Google", этот тоже является переводом статьи от Todd'а Hoff'а. Возможно читателям Google был более интересен, но подход Flickr к масштабируемости тоже более чем заслуживает внимания. Далее привожу источники информации из оригинальной статьи:

Flickr и PHP (ранний документ)
Планирование нагрузок на LAMP
Федерация Flickr: Тур по архитектуре Flickr
Построение масштабируемых веб-сайтов от Call Handerson'а из Flickr
История войн баз данных #3: Tim O'Reilly о Flickr
Cal Henderson's Talks - много полезных презентаций

Платформа

PHP
MySQL
Сегментирование (прим.: разбиение системы на части, обслуживающие каждая свою группу пользователей; называть можно было по-разному, но давайте остановимся на этом варианте перевода слова "Shards")
Memcached для кэширования
Squid в качестве обратной-прокси для html и изображений
Linux (RedHat)
Smarty в роли шаблонизатора
Perl
PEAR для парсинга e-mail и XML
ImageMagick для обработки изображений
Java для узлового сервиса
Apache
SystemImager для развертывания систем
Ganglia для мониторинга распределенных систем
Subcon хранит важные системные конфигурационные файлы в SVN-репозитории для легкого развертывания на машины в кластере.
Cvsup для распространения и обновления коллекций файлов по сети

Статистика

Более четырех миллиардов запросов в день
Примерно 35 миллионов фотографий в кэше Squid
Около двух миллионов фотографий в оперативной памяти Squid
Всего приблизительно 470 миллионов изображений, каждое представлено в 4 или 5 размерах
38 тысяч запросов к memcached (12 миллионов объектов)
2 петабайта дискового пространства
Более 400000 фотографий добавляются ежедневно

Архитектура

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

Два ServerIron
Squid кэши
Системы хранения NetApp
Серверы PHP приложений
Менеджер хранения данных
Master-master сегменты
Центральная база данных, структурированная по принципу Dual Tree
Memcached кластер
Поисковая система

Хранение данных

Структура Dual Tree является индивидуальным набором модификаций для MySQL, позволяющим масштабировать систему путем добавления новых мастер-серверов без использования кольцевой архитектуры. Эта система позволяет экономить на масштабировании, так как варианты мастер-мастер требовали бы удвоенных вложений в оборудование.
Центральная база данных включает в себя таблицу пользователей, состоящую из основных ключей пользователей (несколько уникальных идентификационных номеров) и указатель на сегмент, на котором может быть найдена остальная информация о конкретном пользователе.
Использование выделенных серверов для статического контента
Все, за исключением фотографий, хранится в базе данных
Отсутствие состояний заключается в том, что в случае необходимости они имеют возможность передать пользователей от сервера к серверу, что стало намного проще для них после создания своего API
В основе масштабируемости лежит репликация, но этот факт помогает лишь при обработке операций чтения
Для поиска по определенной части базы данных создается отдельная копия этого фрагмента
Использования горизонтального масштабирования для того чтобы можно было проще добавлять новые машины в систему
Обработка изображений, полученных от пользователей по электронной почте, происходит с помощью PHP
Раньше система страдала от задержек связанных с организацией по принципу мастер-слуга. При слишком большой нагрузке они имели одну точку, которая теоретически могла дать сбой.
Им было необходимо иметь возможность проводить технические работы во время непрерывной работы сайта, не прекращая его функционирование.
Были проведены отличные работы по планированию распределения дискового пространства, более подробную информацию можно найти по ссылкам в разделе "Источники информации".
Для обеспечения возможности масштабирования в будущем, они пошли по федеративному пути развития:
- Сегменты системы: Мои данные хранятся на моем сегменте, но запись о Вашем комментарии хранится на Вашем сегменте.
- Глобальное кольцо: Принцип работы схож с DNS, Вам необходимо знать куда Вы хотите пойти и кто контролирует то место, куда Вы собираетесь пойти.
- Логика на PHP устанавливает соединение с сегментом и поддерживает целостность данных (10 строк кода с комментариями!)
Сегменты:
- Срез основной базы данных
- Активная репликация по принципу мастер-мастер: имеет несколько недостатков в MySQL 4.1. Автоматическое инкрементирование идентификационных номеров используется для поддержания системы в режиме одновременной активности обоих серверов в паре
- Привязывание новых учетных записей к сегментам системы происходит случайным образом
- Миграция пользователей проводится время от времени для того, чтобы избавиться от проблем, связанных с излишне активными пользователями. Необходима сбалансированность в этом процессе, особенно в случаях с большим количеством фотографий… 192 тысячи фотографий, 700 тысяч тэгов, может занять несколько минут. Миграция выполняется вручную.
Нажатие на Favorite:
- Получается информация об учетной записи владельца из кэша для того, чтобы узнать к какому сегменту он привязан (допустим на shard-5)
- Получается информация о моей учетной записи из кэша, более конкретно - мой сегмент (например shard-13)
- Начинается "распределенная транзакция" для определения ответов на вопросы: Кто добавил эту фотографию в избранное? Как изменился список избранных фотографий?
Подобные вопросы могут задаваться любому сегменту, информация на них абсолютно избыточна.
Для избавления от задержек, связанных с репликацией...
- при каждой загрузке страницы, пользователю предоставляется список серверов
- если сервер не в состоянии ответить на запрос, запрос переходит к следующему серверу в списке; если список кончился - выводится сообщение об ошибке. При этом не используются постоянные соединения, каждый раз создаются и разрываются новые соединения.
Запросы на чтение и запись от каждого пользователя ограничиваются рамками одного сегмента. Задержки репликации исчезают из поля зрения пользователей.
Каждый сервер в рамках одного сегмента в обычном состоянии нагружен ровно на половину. Выключите половину серверов в каждом сегменте и система продолжит функционировать без изменений. Это значит, что один сервер внутри сегмента может взять на себя всю нагрузку второго, в то время как второй сервер может по каким либо причинам быть отключен от системы, например для проведения технических работ. Обновление оборудования производится очень просто: отключается половина сегмента, она же обновляется, подключается обратно, процесс повторяется для оставшейся половины.
Периоды пиковой нагрузки также нарушают правило 50% нагрузки. В такие моменты система получает 6-7 тысяч запросов в секунду, в то время как на данный момент система может работать на пятидесятипроцентном уровне нагрузки только при четырех тысячах запросов в секунду.
В среднем при загрузке одной страницы выполняется 27-35 SQL-запросов. Списки избранных фотографий обрабатываются в реальном времени, ровно как и доступ через API к базе данных. Все требования к нагрузке в реальном времени выполняются без каких-либо недостатков.
Более 36 тысяч запросов в секунду может выполняться не выходя за рамки возможностей системы, даже при резком росте трафика.
Каждый сегмент содержит данные о более чем 400 тысячах пользователей.
Многие данные хранятся в двух местах одновременно. Например, комментарий является частью между комментатором и автором комментируемого контента. Где его хранить? Как насчет обоих мест? Транзакции используются для предотвращения рассинхронизации данных: открывается первая транзакция, выполняется запись, открывается вторая транзакция, выполняется запись, подтверждается первая транзакция если все нормально, после чего вторая подтверждается только в случае если первая прошла успешно.

Поиск

Используется два варианта поиска: поиск в рамках сегмента, поддерживающий до 35 тысяч запросов в секунду, а также проприетарный веб-поиск от Yahoo!
В 90% случаев используется система от Yahoo!, за исключением поиска по тэгу фотографий одного пользователя и массовых изменений тэгов.
Эту систему стоит рассматривать как аналог Lucene.

Оборудование

EMT64 под управлением RHEL 4 с 16 Gb оперативной памяти.
6 жестких дисков с 15000rpm, объединены в RAID-10.
Размер для пользовательских метаданных достигает 12 терабайт (это не включает фотографии, для них цифры существенно больше).
Используются 2U корпуса.

Резервное копирование данных

ibbackup выполняется регулярно посредством cron daemon'а, на каждом сегменте настроен на разное время.
Каждую ночь делается снимок со всего кластера баз данных.
Запись или удаление нескольких больших файлов с резервными копиями одновременно на реплицирующую систему хранения может сильно сократить производительность системы вцелом на последующие несколько часов из-за процесса репликации. Выполнение этого на активно работающей системе хранения фотографий было бы не самой лучшей идеей.
Содержание нескольких резервных копий всех Ваших данных требует существенных материальных затрат, но оно того стоит. Особенно это актуально для тех ситуаций, когда Вы понимаете, что что-то пошло не так только спустя несколько дней после того как это случилось, в таких случаях неплохо иметь, например, резервные копии 1, 3, 10 и 30-дневной давности.
Фотографии хранятся в системе хранения данных. После загрузки изображения система выдает различные его размеры, на чем ее работа заканчивается. Метаданные и ссылки на файловые системы, где расположены фотографии, хранятся в базе данных.
Агрегация данных проходит очень быстро, так как она ограничена пределами сегмента.
max_connections = 400 соединений на каждый сегмент, неплохой запас. Значение для кэша потоков установлено равным 45, так как не бывает ситуаций когда более 45 пользователей одновременно выполняют какие-либо действия с одним конкретным сегментом.

Тэги

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

Направления для развития

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

Подводим итоги

Старайтесь думать о своем приложении как о чем-то большем, чем просто веб-приложении, тогда у Вас возможно появятся поддержка различных API, RSS и Atom ленты и многие другие возможности.
Отсутствие состояний системы позволяет более легко выполнять модернизации не моргнув и глазом.
Реструктуризация базы данных - не самое лучшее занятие.
Планирование нагрузок должно проводиться уже на ранних этапах развития проекта
Начинайте медленно. Не покупайте сразу много оборудования просто из-за того, что Вы рады/боитесь, что ваш сайт взорвется.
Измеряйте реально, планирование нагрузок должно базироваться на реальных вещах, а не абстрактных.
Внедряйте ведение логов и индивидуальные измерения для оценки реальных показателей на основе серверной статистики, статистика использования не менее важна чем серверная.
Кэширование и оперативная память может стать ответом на все вопросы.
Создавайте четкие уровни абстракции между работой базы данных, бизнес-логикой, логикой страниц, разметкой страниц и презентационным уровнем. Это позволяет ускорить циклы итеративной разработки.
Разделение приложения на уровни позволяет каждому заниматься своим делом: разработчики могут строить логику страниц, в то время как дизайнеры работают с удобством работы для пользователей.
Делайте релизы как можно чаще, пускай даже это будет происходить каждые полчаса.
Забудьте о всех небольших эффективных вещах, предварительная оптимизация является корнем всего зла в примерно 97% всех случаев.
Тестируйте в работе. Постройте архитектурные механизмы (флаги конфигурации, балансировку нагрузки, и так далее), которые позволят Вам разворачивать новое оборудование в (и из) работу.
Забудьте об искусственных тестах, они годятся только для получения общего представления о нагрузках, но не для планирования. Искуственные тесты дают искусственные результаты, для настоящих тестов все же стоит пользоваться реальным временем выполнения задач.
Найдите максимальное значения для всех показателей:
- Какой максимум чего-то, что может выполнять каждый сервер?
- Как близко параметр находится к максимуму и каковы тенденции?
- MySQL (дисковый ввод/вывод?)
- Squid (дисковый ввод/вывод? или процессорное время?)
- Memcached (процессорное время? или пропускная способность?)
Старайтесь учесть особенности использования Вашего приложения.
- Возможен ли резкий рост нагрузки, связанный с каким-либо событием? Например: какое-либо бедствие, или может быть новость?
- Flickr получает на 20-40% больше новых фотографий в первый рабочий день нового года, чем в любой пик в предыдущем году.
- По воскресеньям нагрузка в среднем на 40-50% выше, чем в любой другой день недели.
Учтите возможность экспоненциального роста. Больше пользователей означает больше контента, больше контента означает больше соединений, больше соединений означает более активное использование.
Планируйте возможные варианты управления работой системы в периоды пиковых нагрузок.

Архитектура Google

Иван Блинков — Thu, 31 Jan 2008 18:05:00 +0300

Эта статья датируется 2008 годом, новая версия: Архитектура Google 2011

Google - Король масштабируемости.

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

Источники информации

Сразу хочу сказать, что эта запись является переводом с английского, автор оригинальной версии - Todd Hoff. Оригинал написан приблизительно в середине 2007 года, но по-моему до сих пор очень даже актуально.

Далее следует перечисление источников информации из оригинала:

Платформа

Linux
Большое разнообразие языков программирования: Python, Java, C++

Что внутри?

Статистика

На 2006 год система включала в себя 450000 недорогих серверов
За 2005 год было проиндексировано 8 миллиардов страниц. На данный момент… кто знает?
На момент написания оригинала Google включает в себя более 200 GFS кластеров. Один кластер может состоять из 1000 или даже 5000 компьютеров
Десятки и сотни тысяч компьютеров получают данные из GFS кластеров, которые насчитывают более 5 петабайт дискового пространства. Суммарные пропускная способность операций записи и чтения между дата центрами может достигать 40 гигабайт в секунду
BigTable позволяет хранить миллиарды ссылок (URL), сотни терабайт снимков со спутников, а также настройки миллионов пользователей

// Цифры не первой свежести конечно, но тоже неплохо.

Стек

Google визуализирует свою инфраструктуру в виде трехслойного стека:

Продукты: поиск, реклама, электронная почта, карты, видео, чат, блоги
Распределенная инфраструктура системы: GFS, MapReduce и BigTable
Вычислительные платформы: множество компьютеров во множестве датацентров
Легкое развертывание для компании при низком уровне издержек
Больше денег вкладывается в оборудование для исключения возможности потерь данных

Надежное хранение данных с помощью GFS

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

Она предоставляет:
- высокую надежность дата центров
- масштабируемость до тысяч сетевых узлов – высокую пропускную способность операций чтения и записи
- поддержку больших блоков данных, размер которых может измеряться в гигабайтах
- эффективное распределение операций между датацентрами для избежания возникновения "узких мест" в системе
В системе существуют мастер-сервера и сервера, собственно хранящие информацию:
- Мастер-сервера хранят метаданные для всех файлов. Сами данные хранятся блоками по 64 мегабайта на остальных серверах. Клиенты могут выполнять операции с метаданными на мастер-серверах, чтобы узнать на каком именно сервере расположены необходимые данные.
- Для обеспечения надежности один и тот же блок данных хранится в трех экземплярах на разных серверах, что обеспечивает избыточность на случай сбоев в работе какого-либо сервера.
- Новые приложения могут пользоваться как существующими кластерами, так и новыми, созданными специально для них.
- Ключ успеха заключается в том, чтобы быть уверенными в том, что у людей есть достаточно вариантов выбора для реализации их приложений. GFS может быть настроена для удовлетворения нужд любого конкретного приложения.

Работаем с данными при помощи MapReduce

Теперь, когда у нас есть отличная система хранения, что же делать с такими объемами данных? Допустим, у нас есть много терабайт данных, равномерно распределенных между 1000 компьютерами. Коммерческие базы данных не могут эффективно масштабироваться до такого уровня, именно в такой ситуации в дело вступает технология MapReduce.
MapReduce является программной моделью и соответствующей реализацией обработки и генерации больших наборов данных. Пользователи могут задавать функцию, обрабатывающую пары ключ/значение для генерации промежуточных аналогичных пар, и сокращающую функцию, которая объединяет все промежуточные значения, соответствующие одному и тому же ключу. Многие реальные задачи могут быть выражены с помощью этой модели. Программы, написанные в таком функциональном стиле автоматически распараллеливаются и адаптируются для выполнения на обширных кластерах. Система берет на себя детали разбиения входных данных на части, составления расписания выполнения программ на различных компьютерах, управления ошибками, и организации необходимой коммуникации между компьютерами. Это позволяет программистам, не обладающим опытом работы с параллельными и распределенными системами, легко использовать все ресурсы больших распределенных систем.
Зачем использовать MapReduce? – Отличный способ распределения задач между множеством компьютеров – Обработка сбоев в работе – Работа с различными типами смежных приложений, таких как поиск или реклама. Возможно предварительное вычисление и обработка данных, подсчет количества слов, сортировка терабайт данных и так далее – Вычисления автоматически приближаются к источнику ввода-вывода
MapReduce использует три типа серверов:
- Master: назначают задания остальным типам серверов, а также следят за процессом их выполнения
- Map: принимают входные данные от пользователей и обрабатывают их, результаты записываются в промежуточные файлы
- Reduce: принимают промежуточные файлы от Map-серверов и сокращают их указанным выше способом
Например, мы хотим посчитать количество слов на всех страницах. Для этого нам необходимо передать все страницы, хранимые в GFS, на обработку в MapReduce. Этот процесс будет происходить на тысячах машин одновременно с полной координацией действий, в соответствии с автоматически составленным расписанием выполняемых работ, обработкой потенциальных ошибок, и передачей данных выполняемыми автоматически.
- Последовательность выполняемых действий выглядела бы следующим образом: GFS → Map → перемешивание → Reduce → запись результатов обратно в GFS
- Технология MapReduce состоит из двух компонентов: соответственно map и reduce. Map отображает один набор данных в другой, создавая тем самым пары ключ/значение, которпыми в нашем случае являются слова и их количества.
- В процессе перемешивания происходит агрегирование типов ключей.
- Reduction в нашем случае просто суммирует все результаты и возвращает финальный результат.
В процессе индексирования Google подвергает поток данных обработке около 20 разных механизмов сокращения. Сначала идет работа над всеми записями и агрегированными ключами, после чего результат передается следующему механизму и второй механизм уже работает с результатами работы первого, и так далее.
Программы могут быть очень маленькими, всего лишь от 20 до 50 строк кода.
Единственной проблемой могут быть "отстающие компьютеры". Если один компьютер работает существенно медленнее, чем все остальные, это будет задерживать работу всей системы в целом.
Транспортировка данных между серверами происходит в сжатом виде. Идея заключается в том, что ограничивающим фактором является пропускная способность канала и ввода-вывода, что делает резонным потратить часть процессорного времени на компрессию и декомпрессию данных.

Хранение структурированных данных в BigTable

BigTable является крупномасштабной, устойчивой к потенциальным ошибкам, самоуправляемой системой, которая может включать в себя терабайты памяти и петабайты данных, а также управлять миллионами операций чтения и записи в секунду.
BigTable представляет собой распределенный механизм хэширования, построенный поверх GFS, а вовсе не реляционную базу данных и, как следствие, не поддерживает SQL-запросы и операции типа Join.
Она предоставляет механизм просмотра данных для получения доступа к структурированным данным по имеющемуся ключу. GFS хранит данные не поддающиеся пониманию, хотя многим приложениям необходимы структурированные данные.
Коммерческие базы данных попросту не могут масштабироваться до такого уровня и, соответственно, не могут работать с тысячами машин одновременно.
С помощью контролирования своих низкоуровневых систем хранения данных, Google получает больше возможностей по управлению и модификации их системой. Например, если им понадобится функция, упрощающая координацию работы между датацентрами, они просто могут написать ее и внедрить в систему.
Подключение и отключение компьютеров к функционирующей системе никак не мешает ей просто работать.
Каждый блок данных хранится в ячейке, доступ к которой может быть предоставлен как по ключу строки или столбца, так и по временной метке.
Каждая строка может храниться в одной или нескольких таблицах. Таблицы реализуются в виде последовательности блоков по 64 килобайта, организованных в формате данных под названием SSTable.
В BigTable тоже используется три типа серверов:
- Master: распределяют таблицы по Tablet-серверам, а также следят за расположением таблиц и перераспределяют задания в случае необходимости.
- Tablet: обрабатывают запросы чтения/записи для таблиц. Они разделяют таблицы, когда те превышают лимит размера (обычно 100-200 мегабайт). Когда такой сервер прекращает функционирование по каким-либо причинам, 100 других серверов берут на себя по одной таблице и система продолжает работать как-будто ничего не произошло.
- Lock: формируют распределенный сервис ограничения одновременного доступа. Операции открытия таблицы для записи, анализа Master-сервером или проверки доступа должны быть взаимоисключающими.
Локальная группировка может быть использована для физического хранения связанных данных вместе, чтобы обеспечить лучшую локализацию ссылок на данные.
Таблицы по возможности кэшируются в оперативной памяти серверов.

Оборудование

Как эффективно организовать большую группу компьютеров с точки зрения издержек и производительности?
Используется самое обыкновенное ультра-дешевое оборудование и поверх него строится программное обеспечение, способное спокойно пережить смерть любой части оборудования.
Тысячекратный рост вычислительной мощности может быть достигнут с издержками в 33 раза меньшими, если воспользоваться толерантной к сбоям инфраструктурой, по сравнению с инфраструктурой, построенной на высоконадежных компонентах. Надежность строится поверх ненадежных компонентов.
Linux, домашнее размещение серверов, материнские платы предназначенные для персональных компьютеров, дешевые средства хранения данных.
Цена за каждый ватт энергии в расчете на производительность не становится меньше, что ведет к большим проблемам связанным с энергообеспечением и охлаждением.
Использование совместного размещения в своих и арендуемых датацентрах.

Разное

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

Пути развития

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

Подводим итоги

Инфраструктура может быть конкурентным преимуществом. Это определенно так для Google. Они могут выпускать новые интернет сервисы быстрее, с меньшими издержками, на таком уровне, что мало кто сможет составить им конкуренцию. Подход многих компаний сильно отличается от подхода Google, эти компании рассматривают инфраструктуру как статью расходов, они обычно используют совсем другие технологии и совсем не задумываются о планировании и организации своей системы. Google позиционирует себя как компанию по построению систем, что является очень современным подходом к разработке программного обеспечения.
Охватывание нескольких дата центров до сих пор является нерешенной проблемой. Большинство сайтов базируется в одном или двух дата центрах. Полное распределение сайта между несколькими датацентрами является хитрой задачей.
Взгляните на Hadoop, если у Вас нет времени на собственноручное построение всей архитектуры с нуля. Hadoop является opensource воплощением в жизнь многих идей здесь представленных.
Часто недооцениваемым преимуществом платформенного подхода является тот факт, что даже неопытные разработчики могут быстро и качественно реализовывать трудоемкие приложения на базе платформы. Но если бы каждый проект требовал одинаково распределенной архитектуры, то это создало бы много проблем, так как люди, которые понимают как это делается, являются достаточно большой редкостью.
Совместная деятельность не всегда является таким уж плохим занятием. Если все части системы работают взаимосвязанно, то улучшение в одной из них сразу и абсолютно прозрачно отразится положительным образом и на остальных компонентах системы. В противном случае такой эффект наблюдаться не будет.
Построение самоуправляемых систем позволяет более легко перераспределять ресурсы между серверами, расширять систему, отключать некоторые компьютеры и элегантно проводить обновления.
Производить длительные операции стоит параллельно.
Всему, что было сделано Google, предшествовало искусство, а не только крупномасштабное развертывание системы.
Учитывайте возможность компрессии данных, она является очень неплохим решением, если остается лишнее процессорное время, но присутствует нехватка пропускной способности.