Еще в этой серии: Распределенная согласованность — Часть 1 — Введение В части 1 мы рассмотрели классы поведения C и A. Для класса A нам нужны более слабые ограничения согласованности. Это не означает, что система должна быть полностью некорректной, но означает, что нам нужно в некоторой мере ослабить согласованность модели. Amazon популяризировал концепцию «Конченой согласованности». Вот их определение: система хранения гарантирует, что если не было новых обновлений объекта, в конечном счете все точки доступа будут возвращать последнее обновленное знчение.

Это не ново, но здорово, когда концепция сформулирована/популяризирована. Несколько примеров систем с конечной согласованностью:

1. DNS
2. Асинхронная мастер/слэйв репликация в реляционных СУБД (и в MongoDB тоже).
3. Memcached перед MySQL, чтение из кэша

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

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

Формы согласованности

Давайте рассмотрим конкретный пример. Рассмотрим систему, использующую MongoDB в следующей конфигурации:

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

Этот тип системы мы называем «конечная согласованность с одним писателем». Какие ее свойства?

1. Клиент может прочитать устаревшие данные.
2. Клиент может увидеть операции записи вне очереди

Предположим, что мы храним некоторую сущность x в хранилище данных. Предположим, что сущности обладают некоторым первоначальным значением — нулём. Клиентами были произведены следующие операции записи в x:

W(x=3), W(x=7), W(x=5)

Так как система конечно согласована, то если записи в x остановились в какой-то момент, мы знаем, что в конце концов прочитаем из x 5 — это R(x==5). Однако в короткой перспективе клиент может увидеть, например:

R(x==7), R(x==0), R(x==5), R(x==3)

(Заметьте, что для такого поведения необходимо от 2 и более узлов.)

Так как это наша слабейшая форма согласованности — конечная согласованность с беспорядочными(ошибочными) чтениями в короткой перспективе.

Мы можем сделать согласованность строже. Рассмотрим конфигурацию MongoDB на SourceForge (большая диаграма здесь). Эта конфигурация представляет из себя конечную согласованность, но мы не увидим результатов записей в неправильном порядке. Эта система обладает монотонной согласованностью чтения.

Единственное возможное свойство конечной согласованности — это согласованность чтения своих же собственных записей. Это означает, что процессу гарантировано во время чтения увидеть записи, которые он сделал. Это очень полезное свойство, облегчающее программирование. Заметьте, что вышеприведенные примеры не обеспечивают согласованность чтения своих же записей. Также относительно этой модели стоит рассмотреть определение слова «своих же». В web приложениях это может быть пользователь. Если балансировщик нагрузки системы посылает запросы к разным серверам с приложением, согласованность чтениях своих же записей для конкретного сервера с приложением может не удовлетворять потребности реального мира в согласованности.

Пункты проверки конкретного случая

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

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

Автор статьи: Блог MongoDB
Дата: 5 апреля 2010
Оригинал статьи

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

CAP

CAP теорема гласит, что в системе одновременно можно выбрать только две вещи з трех: корректность, доступность, устойчивость к разделению сети. В распределенных системах недоступность некоторых узлов неизбежна и система должна быть устойчивой к этому, поэтому CAP означает, что мы не можем одновременно поддерживать корректность и 100% доступности.

Я бы сказал, что теорема CAP означает, что если сеть разорвана, ваша база данных не будет работать.

Однако, мы должны подобрать определение фразе «не будет работать». Это может означать падение (недоступность) или некорректность (старые данные).

Если быть более точными, что мы имеем ввиду под «корректностью»? Академические работы в этой области ссылаются на «упорядочиваемость в одну копию» или «линеаризуемость». Если выполнена серия операций или транзакций, они применены в корректном порядке. Менее формальный способ понимания компромисса: «Могу я читать и управлять старыми/плохими данными? Могу ли я всегда производить запись?»

Объединение

У нас есть два класса архитектур: класс C (строгая корректность) и класс A (более высокая доступность, менее согласованная). Давайте рассмотрим некоторые распределенные системы из реального мира, и к какому классу они отнесены.

Amazon Dynamo — распределенное хранилище данных, которое реализует согласованное хэширование и оно входит в группу A. Оно предоставляет конечную согласованность. Возможна ситуация чтения старых данных.

CouchDB обычно используется с синхронными мастер-мастер репликациями и она тоже в группе A. Она предоставляет конечную согласованность.

Кластер MongoDB с автоматическим шардингом и репликацией в каждый момент времени для каждого шарда обладает мастер сервером. Она в группе C. Традиционные реляционные СУБД системы также строго корректны (при обычном использовании) — например, синхронный кластер реляционной СУБД.

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

Главный вопрос — доступность на запись, а не доступность на чтение

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

Компромиссы:

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

Мы обсудим эти плюсы и минусы более детально в последующих статьях.

Автор статьи: Блог MongoDB
Дата: 26 марта 2010
Оригинал статьи

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

• Вымысел: «Cassandra полагается на высокоскоростное оптоволокно между датацентрами» и не может реплицироваться между датацентрами, latency между которыми более чем несколько мс.
  Факт: Репликация между несколькими датацентрами одна из самых первых возможностей Cassandra и она несомненно является наиболее протестированной в боевых условиях среди NoSQL проектов. Facebook развернул Cassandra в датацентрах на восточном и западном побережьях перед тем как открыть ее в open source. Кластер Сassandra SimpleGeo занимает 3 зоны доступности EC2, и Digg тоже развернул систему на обоих побережьях. Утверждения о том, что это не может работать, являются отличным признаком, что вы читаете статью того, кто не знает о чем говорит.
• Вымысел: «Не возможно определить когда реплики Cassandra будут обновлены.»
  Факт: Cassandra обеспечивает согласованность когда R + W > N (read replica count + write replica count > replication factor), чтобы использовать Dynamo словарь. Если вы производите и запись, и чтение с QUORUM, например, вы можете ожидать согласованность данных, как только количество доступных узлов станет достаточно для quorum. Cassandra также предоставляет восстановление при чтении и антиэнтропию, поэтому даже чтение при ConsistencyLevel.ONE будет согласованным после любого из этих событий.
• Вымысел: У Cassandra маленькое сообщество.
  Факт: Хотя популярность никогда не была хорошим показателем для определения корректности, справедливо, что при использовании передовых технологий, хорошо делать это в компании. На момент написания этой статьи в USA поздняя ночь, и есть 175 человек на irc канале Cassandra, 60 на HBase, 32 на Riak и 15 на Voldemort. (6 месяцев назад числа были 90, 45, 12 для Cassandra, HBase и Voldemort. Я еще не посещал #riak тогда.) Участие в списках рассылок показывает похожие результаты. Также интересен тот факт, что создатели Thrudb и Dynomite используют сейчас Cassandra, это показывает, что предсказанная консолидация NoSQL начинается.
• Вымысел: «Cassandra поддерживает только одно пространство ключей а установку.»
  Факт: Это не правда уже почти год (с июня 2009).
• Вымысел: Cassandra не может поддерживать Hadoop или инструменты поддержки такие как Pig.
  Факт: Всегда было ясно посылать выходные данные Hadoop работ в Cassandra, и Facebook, Digg и другие используют Hadoop подобным образом как Cassandra bulk-loader примерно год. Для версии 0.6, я предоставил Hadoop InputFormat и связанный с этим код для того, чтобы позволить Hadoop работам обрабатывать также данные из Cassandra, кооперируюясь с Hadoop, чтобы продолжать обработку на тех узлах, на которых реально есть данные. Также в версии 0.6 Stu Hood предоставил Pig LoadFunc.
• Вымысел: Cassandra достигает высокой производительности жертвуя надежностью (иными словами: Cassandra хороша только для тез данных, которые вы можете себе позволить потерять).
  Факт: В отличии от некоторых NoSQL баз данных (особенно MongoDB и HBase), Cassandra предлагает полную стойкость отдельного сервера. В случаях, когда вы не можете позволить себе потерять данные, недостаточно полагаться на репликацию; если ваш датацентр теряет питание, вы с большой вероятностью потеряете данные, которые не были синхронизированы с диском, неважно сколько у вас при этом есть реплик. И если вы работаете с большими системами в продакшене достаточно долго, вы осознаете, что нельзя игнорировать перебои с питанием, как результат комбинации сбоев оборудования и человеческой ошибки. Но Cassandra со своим fsync commitlog решением может защитить вас и в этом случае тоже. Что делать после того, как ваши данные сохранены (например бэкапами и снэпшотами), я здесь не описываю, но это освещается на странице wiki.

Автор статьи: Jonathan Ellis
Дата: 7 апреля 2010
Оригинал статьи

Верите вы или нет, но первая история произошла в середине 70-х. Во время учебы в средней школе, мне повезло иметь доступ к миникомпьютеру Data General Nova. В отличие от других «космических» компьютеров, Новы были действительно очень крутыми. У них была возможность непрямой адресации, которая означала, что вы можете сделать любой адрес как непрямой, что заставит использовать этот адрес аппаратно как адрес адреса. Эта возможность делала вызовы и передачу параметров очень быстрой. Единственным недостатком была возможность зависания машины, если вы заставляли адрес ссылаться на самого себя). Как бы то ни было, моей задачей было написать программу классификации. Эта программа должна была получать вход на оптических карточках (которые были как перфокарты, с тем отличием, что нужно было заполнять точечки карандашом, вместо того, чтобы пробивать отверстия), сравнивать ответы по ключу и выдавать всевозможные отчеты в качестве результата. Все просто, не так ли?

В те дни, операции ввода/вывода были очень медленными. По крайней мере, нам так рассказывали. Фактически, у нас не было никаких способов улучшить производительность, и я просто принял как данность, что ввод/вывод – очень медленный. Чтобы разобраться с этой проблемой, я решил использовать многозадачность. Я хотел использовать подзадачи, чтобы считывать карточки, в то время как основная задача выполняла классификацию. Крутая идея, да?

Итак, напомню вам:

• Это была одна из первых программ, которых я писал в своей жизни.
• Я решил использовать сложную, не до конца понятную технологию в проект, основываясь на интуиции. Большинство из нас не имело достаточного жизненного опыта в средней школе, чтобы правильно питаться, не говоря уж о интуитивных выборах технологий.
• Все это программировалось на Фортране, который и сегодня не очень-то предназначен для многозадачности, а уж 40 лет назад…
• В те дни не было Интернета. Онлайн вообще было мало что, особенно для уровня средней школы. Это означает, что единственным источником информации были бумажные руководства

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

Но главная моя ошибка была в том, что я использовал абсолютно ненужную вещь. Я поверил, что нашел МегаРешение (в моем случае – многозадачность).

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

Другой пример возник спустя несколько лет в Macy’s. Мы были одними из первых установщиков электронных кассовых аппаратов IBM(да-да, IBM делали кассовые аппараты), что означало установку компьютера в каждый магазин и соединение его со всеми аппаратами в магазине. Верите или нет, но нужно было вручную настраивать софт для каждого магазина, настраивая каждый аппарат по отдельности. Будучи в самом низу иерархии (я ведь еще был подростком, помните?), я занимался именно этим.

Если бы я был умным подростком, я бы просто вбил всю эту конфигурацию и занимался своими делами. Всего было около 10 магазинов, и после первоначальной установки там что-то менялось бы раз в несколько месяцев. Но, так как я не был умным, я решил написать сложный макрос на ассемблере, который бы выполнял работу. Это примерно как писать программу для препроцессора C++ (#define, #ifdef, и т.д.), чтобы сгенерировать C-программу.

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

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

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

Нашей первой реакцией было «Круто! Автоматическое маштабирование! Автоматическое шардирование! Автоматическое удаление SPOF!”

Наша вторая реакция: «Эээ, мм.. а как вы делаете отчеты? Каждое бизнес-решение требует новой программы?» (здесь прячется бизнес-идея для кого-то).

Ладно, я что-то отвлекся. Вопрос в другом – считать ли желание попробовать NoSQL-решения типа Cassandra погоней за очередным МегаРешением? Что ж, я думаю, и да, и нет, и у меня есть компромиссный вариант.

Да, потому что, мы ведь не работаем над Google, Digg, или eBay, и пока что тратить время и силы на попытки подогнать архитектуру под схему, совместимую с Cassandra – это не лучший способ использовать время.

Нет, это не потеря времени, потому что если у нас все получится, то нам не придется потом в панике что-то переделывать, когда мы вырастем, и мы сможем сосредоточиться на других вещах.

С другой стороны, если мы сейчас тратим время на работу с Cassandra, вместо того, что мы знаем (SQL), то это время потеряно для работы непосредственно над проектом.
Компромисс в том, чтобы инкапсулировать доступ к данным так, чтобы большая часть кода не зависела от того, используем мы MySQL, Oracle, Cassandra, или текстовые файлы. Имея опыт нескольких таких инкапсуляций, я могу сказать, что это не так трудно, если вы грамотно продумаете наперед все, что вы хотите сделать.

Итак, подведем итоги:

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

Спасибо за прочтение!

Автор статьи: Michael Wilson
Дата: 30 марта 2010
Оригинал статьи

В этом посте я бы хотел поговорить об основных идеях удаления дубликатов. Удаление дубликатов — это сердце любой современной системы онлайн бэкапа и облачной системы хранения данных. Давайте посмотрим, как это все работает.

Создание бэкапов ваших данных

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

Как определить, что изменилось со времени прошлого бэкапа?

Побайтовое сравнение содержимого файлов работает слишком медленно, особенно при больших размерах файлов. Нам нужно что-то типа «отпечатка пальцев», чтобы мы могли быстро сказать, идентичны файлы или нет. Отпечаток пальцев (или идентификатор) обычно реализуется как хэш функция (md5, sha256 и др). Бэкап с исключением повторных файлов намного более эффективен, чем бэкап в виде простой копии. Но это по-прежнему слабый метод в случае, когда огромные файлы рамером в несколько гигабайт претерпевают изменение в 1 байте. В этом случае мы обнаружим это изменение и с радостью забэкапим целиком новую версию. Есть ли способ улучшить этот метод?

Удаление дубликатов блока

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

Основные идеи удаления дубликатов

Блоки идентифицируются и сравниваются с помощью этих идентификаторов.

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

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

Случаи модификации данных

Так как же модифицируются данные? Существуют три основных вида модификации данных: вставка, обновление, удаление. Любая модификация данных может быть представлена как последовательность этих основных действий.

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

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

Идея плавающего окна для поимки границ блока

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

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

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

Улучшение производительности использованием кольцевого хэширования

Производительность определения вставленных/удаленных данных с помощью плавающего окна основывается на производительности вычисления идентификатора для данного блока со смещением A и длиной N. В общем, мы имеем дело с вычислением хэш функции с O(N) операциями. Так как нам нужно посчитать идентификаторы для всех смещений с 0 до N, то производительность плавающего окна уменьшается до O(N^2), а это уже не практично для блоков большого размера. Все, что нам нужно, — это каким-то образом получить преимущество подсчета хэш функции для смещения A + 1 за счет того, что мы уже посчитали хэш функцию для смещения A. К счастью, существует хэш функция кольцевого хэширования Adler32, которая нам в этом поможет. Таким образом, мы можем поддерживать плавающее окно с сложностью O(N) и блоки большого размера.

Коллизии

Давайте посчитаем вероятность коллизии. Предположим, что мы можем хранить N блоков в нашем хранилище, и используем B битов в хэшкоде. Вероятность коллизии в нашем хранилище — это вероятность единичной коллизии 1/2^B , умноженная на количество пар блоков N*(N-1)/2

P=N*(N-1)/2^(B+1)

Для 1Tb данных и блоков размером 32К у нас будет 2^40/2^15=2^25 блоков, то есть N=2^25

P=2^25(2^25-1)/2^257~1/2^207~10^-63

Мы потеряем 32Kb из 1TB с вероятностью 10^-69. Это чрезвычайно редкая ситуация. Получается, что если вы будете делать бэкапы 100 PB данных на протяжении миллиона лет, у вас не будет даже одного шанса на миллиард потерять что-нибудь из-за коллизии.

Удаление дубликатов VS ZIP сжатием

Используя все вышеперечисленные идеи, я создал утилиту удаления дубликатов, которая удаляет дубликаты во всех файлах заданной папки и всех ее подпапках. Для анализа результатов удаления дубликатов я провел две серии тестов.

Я взял один наш проект со всеми исходниками, бинарными файлами и метаданными SCM (мы используем Mercurial). Удаление дубликатов было проведено для 3 снимков нашего проекта с перерывом в 1 месяц, и один раз для всех снимков вместе. Результаты были сравнены с ZIP сжатием с максимальными настройками сжатия. Сравнение приведено в таблице:

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

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

Автор статьи: Vladimir Balandin
Дата: 8 апреля 2010
Оригинал статьи

Puppet, Chef, cfengine, и Bcfg2 – игроки в пространстве управления конфигурациями. Если вы ищете Linux решения для автоматизации или инструменты управления конфигурациями серверов, то вы скорее всего натолкнетесь на такие 2 технологии, как Puppet и Opscode Chef. У них очень похожая архитектура, и они решают одинаковые виды задач. Puppet от Reductive Labs существует дольше, у него большое количество пользователей. Chef от Opscode извлек несколько уроков из разработки Puppet и у него есть клиент высокого уровня – EngineYard. Вам надо сделать важный выбор: на какую систему поставить? Когда вы строите автоматизированную инфраструктуру, скорее всего вы будете работать с ней несколько лет. Когда ваша инфраструктура уже построена, смена технологий стоит дорого. Развертывания Puppet и Chef часто оказываются крупномасштабными, порой они покрывают тысячи серверов. »Chef против Puppet» – это продолжающийся спор, но вот 10 преимуществ, которые сегодня есть у Puppet над Chef по моему мнению.

1. Большее количество инсталляций
   Проще говоря, практически все используют Puppet, а не Chef. В то время как на сайте Chef есть только небольшой список компаний, испольщующих его, у Puppet есть более 80 организаций, в том числе Google, Red Hat, Siemens, большое количество крупных фирм по всему миру, и несколько университетов из основных, включая Stanford и Harward Law School.
   Это значит, что у Puppet серьезные намерения, и облегчает его распространение. Когда люди узнают, что эту же технологию использует Google, они полагают, что она работает. У развертываний Chef нет этого преимущества (пока). Разработчики и системные администраторы часто смотрят на своих коллег в других компаниях для социального доказательства.
2. Большее количество разработчиков
   Puppet настолько широко используется, что большое количество людей работают над ним. У Puppet много контрибуторов в исходный код ядра, но также он породил разнообразие систем поддержки и сторонних дополнений специфичных для Puppet, в том числе Foreman. Популярные инструменты создают свои собственные экосистемы.
   Число разработчиков Chef растет быстро, но пока остает от Puppet, и его разработчики безусловно менее опытны в работе над ним, так как это более молодой проект.
3. Выбор языков конфигурации
   Puppet использует для конфигурирования серверов язык, который специально разработан для этой задачи: это предметно-ориентированный язык, оптимизированный для задачи описания и связывания таких ресурсов, как пользователи и файлы.
   Chef использует расширение Ruby. Ruby хороший язык программирования общего назначения, но он не разрабатывается специально для управления конфигурацией, и обучение Ruby намного сложнее чем обучение язык Puppet.
   Некоторые считают, что отсутствие предметного-ориентированного языка является преимуществом Chef. Они приводят аргумент: «Вы получаете мощь Ruby бесплатно». К сожалению, в Ruby есть много неинтуитивных вещей, особенно для начинающих, также необходимо овладеть большим и сложным синтаксисом.
   В Puppet есть экспериментальная поддержка написания манифестов на языке, встроенном в Ruby, также как в Chef. Поэтому возможно лучше будет сказать, что Puppet дает вам выбор использования либо его предметно-ориентированного языка, либо мощь языка общего назначения Ruby. Я схожусь во мнении с Chris Siebenmann, что проблема использования языков общего назначения для конфигураций в том, что они жертвуют ясностью ради мощи, и это не является выгодным обменом.
4. Более длинный путь в коммерческом использовании
   Puppet находится в коммерческой эксплуатации много лет, и он непрерывно совершенствовался и улучшался. Он развертывался в очень больших инфраструктурах (5000+ машин) и уроки производительности и масштабирования полученные из этих проектов, внесли вклад в разработку Puppet.
   Chef все еще находится на ранней стадии разработки. С моей точки зрения он еще не созрел для промышленного использования. Он не поддерживает столько операционных систем, сколько Puppet. Так что возможно он даже не может рассматриваться как вариант в вашем окружении. Хотя развертывания Chef сущестуют на множестве платформ, поэтому проверяйте доступность для вашей ОС.
5. Лучшая документация
   У Puppet есть огромная поддерживаемая пользователям вики с сотнями страниц документации и исчерпывающих справочных руководств и для языка, и для типов ресурсов. В добавок к этому, он активно обсуждается в нескольких списках рассылок и есть очень популярный IRC канал. Поэтому, какова бы ни была ваша проблема с Puppet, ответ найти легко. (Если вы начинаете знакомиться с Puppet, можете обратиться к моему руководству по Puppet.)
   По вполне понятным причинам разработчики Chef больше сконцентированы на том, чтобы сделать рабочий инструмент, чем на написание обширной документации. Руководства по Chef существуют, но они немного схематичны. Информация есть, но она рассеяна и сложно найти необходимую часть.
6. Больше способов использования
   И Chef, и Puppet могут использоваться как инструмент развертывания. Документация по Chef нацелена на пользователей, развертывающих Ruby on Rails приложения, в частности в облачных окружениях – основной его пользователь это EngineYard, и это чем они занимаются, большая часть руководств направлена на это. Chef не ограничивается Rails, но справедливо будет сказать, что это его основной способ использования.
   Puppet, напротив, не ассоциируется ни с каким конкретным языком или web фреймворком. Его пользователи управляют приложениями Rails, но также PHP приложениями, Python и Django, Mac десктопами или AIX мэйнфреймами с Oracle.
   Необходимо прояснить, что это не является техническим преимуществом Puppet, это результат того, что у его сообщества, документации и использования база более обширна. Чем бы вы не пытались управлять, используя Puppet, вы скорее всего обнаружите, что кто-то уже это сделал и может помочь вам.
7. Поддержка большего количества платформ
   Puppet поддерживает множество платформ. Независимо от того где он запущен, на OS X или на Solaris, Puppet знает какой пакетный менеджер и какие команды использовать для создания ресурсов. Сервер Puppet может быть запущен на любой платформе, которая поддерживает Ruby. Он может быть запущен на довольной устаревших версиях ОС и Ruby (важный момент во многих промылшенных окружениях, которые консервативны в смысле обновления программного обеспечения).
   Chef поддерживает меньшее чем Puppet количество платформ, в большой степени потому, что зависит от недавних версий Ruby и CouchDB. Хотя количество поддерживаемых платформ все время растет, также как и у Puppet. Puppet и Chef могут развертывать все области вашей инфраструктуры, которые находятся в списк поддерживаемых платформ.
8. Не изобретает заново велосипед
   Chef был сильно вдохновлен Puppet. Он в большой степени дублирует функциональность, уже существующую в Puppet – но у него нет всех возможностей Puppet. Если вы уже используете Puppet, Chef не может предложить вам ничего нового, что стоило бы перехода.
   Конечно Puppet тоже переизобрел много функциональности, которая была в предыдущих поколениях программного обеспечения, управляющего конфигурациями, таких как cfengine. Все повторяется.
9. Явное управление зависимостями
   Некоторые ресурсы зависят от других ресурсов – вещи должны быть выполнены в определенном порядке. Chef похоже на shell скрипт: вещи выполняются в том порядке, в котором они написаны, и это все. Но так как нет способа явно сказать, что один ресурс зависит от другого, порядок ваших ресурсов в коде может быть критичен, или нет – читатель не сможет определить это посмотрев на набор команд. Следовательно, рефакторинг и перемещение кода могут быть опасны, простое изменение порядка ресурсов в текстовом файле может сломать работу.
   В Puppet зависимости всегда явные и вы можете свободно менять порядок ресурсов в коде, не влия на порядок приложения. Ресурс в Puppet может «слушать» изменения в вещах, от которых он зависит: если изменяется конфигурация Apache, может быть автоматически вызыван перезапуск Apache. Верно и обратное, ресурсы могут «уведомлять» другие ресурсы, которые могут быть заинтересованы в них. Chef тоже может это делать, но от вас не требуется делать эти зависимости явными – и это с моей точки зрения плохо, хотя некоторые не соглашаются. Andrew Clay Shafer продуманно написал об этом различии: Puppet, Chef, Dependencies and WorldViews).
   Фанаты chef считают, что его поведение детерминировано: одни и те же изменения будут каждый раз применяться в одном и том же порядке. Sterve Traugott и Lance Brown спорят о важности этого свойства в статье Why Order Matters: Turing Equivalence in Automated Systems Administration.
10. Лучшая осведомленность потребителей
    Хотя это не техническик момент, но возможно он самый важный. Когда вы говорите «управление конфигурациями», большинство людей (по крайней мере среди тех, кто знает о чем речь) обычно ответят «Puppet». Puppet владеет этим пространством. Я знаю, что есть большое, готовое помочь сообщество, к которому я могу обратиться, и даже опубликованные книги про Puppet. Puppet настолько широко признан, что фактически любая задача, с которой вы можете столкнуться, уже была кем-то обнаружена и решена.

Заключение

На данный момент «Chef против Puppet» довольно нечестное сравнение. Большинство отмеченных недостатков Chef являются следствием того, что Chef еще очень молод. Технически, Puppet и Chef обладают похожими возможностями, но у Puppet преимущество первого хода и он колонизировал большую часть уголков мира управления конфигурациями. Однажды Chef догнать его, но сегодня я рекомендую Puppet.

Автор статьи: John Arundel
Дата: 12 января 2010
Оригинал статьи

Это часть интервью с Sebastian Stadil, основателем Scalr, дешевой опенсорс-версии RightScale. Scalr заботится об инфраструктурах всех web-сайтов, находящихся на Amazon (и других облаках), так что вам этого делать не приходится.

Я впервые встретил Sebartian на одном из собраний группы Valley Cloud Computing Group, которую он основал. Собрания начались в крошечных офисах Intalio, где Sebastian работал с этими новыми штуками от Amazon для создания фермы автоматически масштабирующихся серверов на EC2. Я хорошо помню, как Sebastian встречал каждого в дверях с улыбкой и рукопожатием, заставляя нас чувствовать себя как дома. Позже я посетил его занятия по использованию AWS. Я думаю, он разобрался со всеми этими облачными вещами и решил организовать Scalr.

Мне очень жаль, что название «Amazon» не начинается с буквы ‘S’ – тогда бы получилось просто эпическое название поста.

Знакомство

В этом разделе – ответы Sebastian на общие вопросы о Scalr.

Что такое Scalr
Scalr – это тот самый парень, которого вы просите помочь разобраться с серверами: Scalr помогает вам создавать масштабируемую инфраструктуру и управлять ей.

Когда ты начал?
Scalr выпущена в свет под GPL лицензией в апреле 2008, так что в следующем месяце мы празднуем двухлетнюю годовщину с Scalr 2.0!

Что заставило тебя покинуть старую работу и начать заниматься Scalr?
Потому что очень сложно построить правильную инфраструктуру! И масштабирование так дорого обходится!

Твой продукт развивался со временем?
Сначала он использовал только EC2 и обходные пути из-за отсутствия EBS. А сейчас это полностью функциональная система, использующая последние фичи Amazon, такие как RDS и ELB, для масштабирования и управления всем для вас.

Можешь сравнить с RightScale и предложениями Amazon?
Представляйте Scalr как опенсорс RightScale, фокусирующийся только на масштабировании web-приложений. Amazon почти не предлагает автоматизации и не помогает вам создавать масштабируемую архитектуру. Если у есть хотя бы маленький шанс, что ваш проект вырастет, ознакомьтесь с нашей системой.

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

7 секретов для успешного масштабирования с Scalr

Я подумал, что Sebastian за много лет приобрел большой опыт работы с AWS, и ему должно быть известно множество трюков и ловушек. Поэтому я попросил рассказать его, о каких главных проблемах следует помнить, когда работаешь с Amazon, и затем объяснить, как Scalr помогает их решать. Вот ответы Sebastian:

Не задавайте четко адреса.
Вещи меняются быстро в облаке, особенно IP адреса. Адрес базы данных, который у вас есть сегодня, может измениться завтра или на следующей неделе. Это может произойти случайно из-за остановки или запуска сущности EC2 или предсказуемо, когда вычисления и данные переезжают по разным пулам ресурсов – например, с EC2 на Rackspace Cloud. Elastic IPs — сервис Amazon для привязки IP к любому серверу — решает эту проблему до тех пор, пока вы продолжаете использовать сервисы Amazon. Но вы не можете назначить его не EC2 серверу, поэтому вы не можете использовать это за пределами AWS.

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

Мы все это упростили в Scalr. Scalr хранит обновленный список IP адресов для каждой сущности и названия сервера в форме записей DNS на кластере серверов имен. Когда вы отправляете запрос к базе данных db.example.com, клиент ищет IP адрес для этого имени сервера в записях DNS для этой зоны и кэширует все это до тех пор, пока не истечет TTL.

Переносите вычисления в Rackspace Cloud? Scalr добавит записи для вашей новой базы данных на Rackspace и удалит ссылки на IP адреса EC2.

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

Кластер мастер-слэйв репликаций – это набор множеств баз данных, которые синхронизируют данные в одном направлении. Мастер-база данных – это хранитель всех данных, и она единственная, в которую вы записываете: INSERT, DELETE и UPDATE. Слэйв-база данных реплицирует данные от мастера и хранит их копию. Из нее вы производите чтение: SELECT. Это разделение освобождает ресурсы в мастере, которые часто ограничены возможностями CPU, и позволяет вам производить JOIN без уничтожения всей производительности, так как обрабатывает эту операцию слэйв, а не мастер.

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

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

Распределять CRON задания очень тяжело
Посмотрите на то, как масштабируются инстансы с cron заданиями на них. Cron задания не проектировались для облака. Если промасштабировать образ машины, содержащей cron задание на 20 инстансов, то получится, что ваше cron задание будет выполняться в 20 раз чаще.

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

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

Apache Software Foundation имеет изящную утилиту для распределенного сервиса блокировок. Она называется Zookeeper. Эта утилита является основанием распределенной системы cron задач от Scalr, поэтому пользователи могут настраивать периодическое выполнение скриптов, таких как cron задачи, и риска того, что задание будет выполнено несколько раз или не выполнено вообще, не будет.

Разработка и продакшн должны быть близнецами.
Различия между окружениями разработки и продакшена могут вызвать сбои при переводе продукта из одного в другое. Что-нибудь незначительное – например, различные размеры инстанса, – может вызвать неполадки, особенно на EC2, где маленькие инстансы 32-битные, а большие 64-битные.

Традиционно компании запускают разработку и QA на выделенных серверах. Так как они используются непостоянно, например, пару недель до релиза, компании обычно экономят, покупая только по одному серверу каждого типа — это особенно верно, когда ваша архитектура требует программы с несвободными лицензиями. Брать дополнительные лицензии на Oracle ради нескольких недель в году может быть очень расточительным поступком.

В облаке все обстоит иначе. Так как ты платишь только за то, что взял, вы можете можете получить сервера на ограниченный период, пока вы их используете. Если вы используете Scalr, то все еще проще: просто клонируйе вашу ферму продакшн серверов и называйте их QA. Используйте их 8 часов в понедельник и затем уже выключайте утром во вторник. У вас будет идеальная копия вашего продакшн окружения (та же архитектура, системы и данные), дневная цена часто ниже цены запуска.

А еще сделайте снэпшот вашей базы данных и запускайте Dev и QA с теми же данными, как в продакшене. Используйте Apache Bench и вы сможете получить даже ту же самую нагрузку.

Учитесь у комьюнити
Достаточно сложно оставаться в курсе всех последних изменений и трюков с инфраструктурой, от Cassandra и Nencached до Varnish и nginx. Я не могу даже представить, сколько нужно времени, чтобы изучить все с нуля

Пока существует множество фреймворков (таких, как построенный нами проект Scalr), и платформ (Heroku и Google App Engine), которые либо упрощают масштабирование, либо абстрагируют все, полезно иметь немного знаний о более нижнем уровне — механике всего этого. Я понял, что чтение OSI модели компьютерных сетей, задачи выбора компромиссных значений в кэшировании, CAP теоремы от Eric Brewer и концепции отложенной согласованности — это все не зря потраченное время.

I/O будут узким местом
Дисковое I/O наверняка будет проблемой в росте вашего приложения, и Raid поверх EBS быстро переполнит сетевое I/O (все пойдет сначала внутрь, а потом наружу, и в итоге будет потребляться двойная пропускная способность). Используйте базу данных оперативной памяти, где это имеет смысл, и кэшируйте все, что только можно! Мы считаем, что memcached достаточно легко использовать, и она очень сильно повлияет на нагрузку базы данных.

Трудно работать с эфемерным хранилищем
Если вы используете локальный диск для хранения данных для лучшего I/O, то вы рискуете потерять данные из-за неисправной работы инстанса. Это может быть ограничено задержкой репликации, временем после последнего снэпшота или временем последнего дампа базы данных, но все это делает восстановление нудным и лакейским.

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

Автор статьи: Todd Hoff
Дата: 22 марта 2010
Оригинал статьи

MapReduce, Bigtable, Pregel берут свое начало в Google и все они имеют дело с «огромными системами». Но все они выглядят мелко по сравнению с новым проектом, над которым работает Google, упомянутым на одном мероприятии в прошлом году.

Выглядит так, что вместо кэширования данных рядом с пользователем, Google пытается «доставить» данные к пользователю. Если вы используете Gmail или Google Docs, тогда Google, используя этот фреймворк, может автоматическим-магическим образом переместить одну из мастер копий ваших данных в ближайший к вам датацентр, при этом не потребуется ничего кэшировать локально. И похоже, что им больше не нужны выделенные кластеры для отдельных проектов, так как они строят единый кластер датацентров по всему миру вместо сотен более мелких для отдельных приложений.

Ниже приведена суть Spanner, извлеченная из разговора с Jeff Dean на симпозиуме в Cornell. Обратите внимание на другие слайды, если вы интересуетеся впечатляющей статистикой производительности и надежности аппаратного обеспечения.

Spanner: Система хранения и вычислений, которая охватывает все наши датацентры

• Единое глобальное пространство имен
  • Имена не зависят от местонахождения данных
  • Сходства с Bigtable: table, families, locality groups, coprocessors…
  • Различия: иерархические директории вместо строк, мелкоструктурная репликация
  • Мелкоструктурные ACL, настройка репликации на уровне директорий
• Поддержка сочетания слабой и сильной согласованности между датацентрами
  • Сильная согласованность реализуется при помощи Paxos реплик
  • Полная поддержка распределенных транзакций между директориями/машинами
• Более автоматизированные операции
  • Система автоматически перемещает и добавляет реплики данных и вычислений основываясь на ограничениях и шаблонах использования
  • Автоматическое выделение ресурсов для всех машин

Автор статьи: Royance Tharakan
Дата: 18 марта 2010
Оригинал статьи

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

Здесь представлена коллекция этих приложений из блога MyNoSQL:

• Twitter использует Cassandra
• MusicTweets использовали Redis – Этот сайт сейчас уже не работает, но вы еще можете почитать о нем
• Tstore использует CouchDB
• Retwis использует CouchDB
• Retwis-RB использует Redis и Sinatra. Sinatra- это не БД хранилище.
• Floxee использует MongoDB
• Twidoop использует Hadoop
• Swordfish построено на Tokyo Cabinet
• Tweetarium использует Tokyo Cabinet

Автор статьи: Royans Tharakan
Дата: 23 февраля 2010
Оригинал статьи