Colossus. Распределенная файловая система от Google

    Colossus (или GFS2) – это проприетарная распределенная файловая система от Google, запущенная на production-серверах в 2009 году. Colossus является эволюционным развитием GFS. Как и ее предшественник GFS, Colossus оптимизирована для работы с большими наборами данных, прекрасно масштабируется, является высокодоступной и отказоустойчивой системой, а также позволяет надежно хранить данные.

    В то же время, Colossus решает часть задач, с которыми GFS не справлялась, и устраняет некоторые узкие места предшественника.


    Зачем понадобился GFS2? Ограничения GFS


    Одним из таких принципиальных ограничений связки «GFS + Google MapReduce», как и аналогичной связки «HDFS + Hadoop MapReduce (Classic)» (до появления YARN), была ориентированность исключительно на пакетную обработку данных. В то время как все больше сервисов Google – социальные сервисы, облачное хранилище, картографические сервисы – требовали значительно меньших задержек, чем те, которые свойственны пакетной обработке данных.

    Таким образом, в Google столкнулись с необходимостью поддержки near-real-time ответов для некоторых типов запросов.

    Кроме того, в GFS chunk имеет размер 64 Мб (хотя размер chunk конфигурируемый), что, в общем случае, не подходит для сервисов Gmail, Google Docs, Google Cloud Storage — бОльшая часть места выделенного под chunk остается незанятой.

    Уменьшение размера chunk автоматически привело бы к увеличению таблицы метаданных, в которой хранится file-to-chunk маппинг. А так как:
    • доступ, поддержка актуальности и репликация метаданных – это зона ответственности Master сервера;
    • в GFS, как и в HDFS, метаданные полностью загружаются в оперативную память сервера,
    то очевидно, что один Master на GFS-кластерпотенциально узкое место в распределенной файловой системе с большим числом chunk'ов.

    Кроме того, современные сервисы являются географически распределенными. Геораспределенность позволяет как остаться сервису доступным во время форс-мажоров, так и сокращает время доставки контента до пользователя, который его запрашивает. Но архитектура GFS, описанная в [1], как классическая «Master-Slave»-архитектура, не предполагает реализацию географической распределенности (во всяком случае без существенных издержек).

    Архитектура


    (Disclaimer: я не нашел ни одного достоверного источника, в полной мере описывающего архитектуру Colossus, поэтому в описании архитектуры имеются как пробелы, так и предположения.)

    Colossus был призван решить проблемы GFS, описанные выше. Так размер chunk'а был уменьшен до 1 Мб (по умолчанию), хотя по-прежнему остался конфигурируемым. Возрастающие требования Master-серверов к объему оперативной памяти, необходимой для поддержания таблицы метаданных, были удовлетворены новой «multi cell»-ориентированной архитектурой Colossus.

    Так в Colossus есть пул Master-серверов и пул chunk-серверов, разделенных на логические ячейки. Отношение ячейки Master-серверов (до 8 Master-серверов в ячейке) к ячейкам Сhunk-серверов является один ко многим, то есть одна ячейка Master-серверов обслуживает одну и более ячейку Сhunk-серверов.

    Colossus architecture

    Внутри ЦОД группа ячейка Master-серверов и управляемые ей ячейки Chunk-серверов образуют некоторую автономную — не зависящую от других групп такого типа – файловую систему (далее для краткости SCI, Stand-alone Colossus Instance). Такие SCI расположены в нескольких ЦОД Google и взаимодействуют друг с другом посредством специально разработанного протокола.

    Colossus architecture

    Т.к. в открытом доступе нет подробного описанного инженерами Google внутреннего устройства Colossus, то не ясно, как решается проблема конфликтов, как между SCI, так и внутри ячейки Master-серверов.

    Один из традиционных способов решения конфликтов между равнозначными узлами – это кворум серверов. Но если в кворуме четное количество участников, то не исключены ситуации, когда кворум ни к чему и не придет – половина «за», половина «против». А так как в информации о Colossus очень часто звучит, что в ячейке Master-серверов может находится до 8 узлов, то решение конфликтов с помощью кворума ставится под сомнение.

    Также совершенно не ясно, каким образом одна SCI знает, какими данными оперирует другая SCI. Если предположить, что такими званиями SCI и не обладает, то это означает, что этими знаниями должен обладать:
    • либо клиент (что еще менее вероятно);
    • либо (условно) Supermaster (который опять же является единичной точкой отказа);
    • либо это информация (по сути critical state) должна находится в разделяемом всеми SCI хранилище. Тут ожидаемо возникают проблемы блокировок, транзакций, репликации. С последними успешно справляется PaxosDB, либо хранилище реализующее алгоритм Paxos (или аналогичный).

    В общем Colossus в целом пока скорее «черный ящик», чем «ясная архитектура» построения геораспределенных файловых систем, оперирующих петабайтами данных.

    Заключение


    Как видно, изменения в Colossus коснулись почти всех элементов файловой системы предшественника (GFS) – от chunk, до композиции кластера; вместе с тем, сохранена преемственность идей и концепций, заложенных в GFS.

    Одним из наиболее «звездных» клиентов Colossus является Caffeine — новейшая инфраструктура поисковых сервисов Google.

    Список источников*


    [1] Sanjay Ghemawat, Howard Gobioff, Shun-Tak Leung. The Google File System. ACM SIGOPS Operating Systems Review, 2003.
    [10] Andrew Fikes. Storage Architecture and Challenges. Google Faculty Summit, 2010.
    * Полный список источников, используемый для подготовки цикла.

    Дмитрий Петухов,
    MCP, PhD Student, IT-зомби,
    человек с кофеином вместо эритроцитов.

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 12

      +1
      А так как в информации о Colossus очень часто звучит, что в ячейке Master-серверов может находится до 8 узлов, то решение конфликтов с помощью кворума ставится под сомнение.

      Может быть что-то типа Арбитра в Mongodb
      Арбитр
      image


      Также совершенно не ясно, каким образом одна SCI знает, какими данными оперирует другая SCI.

      Может быть какие-то дополнительные config-сервера (опять же, пример из mongodb).

      Остается только догадываться...
        0
        В mongodb нет голосования. Там есть timestamp последнего изменения. У кого он больше, тот и master. Но чтобы не допустить split brain ситуации, master'а может выбирать только группа серверов, видящая более половины всех серверов.
          +1
          Есть замечательный человек, который пишет по поводу consistency в распределенных системах и о распределенных ситсемах:
          Блог
          Спич
          В общем суть такова, что решения в общем виде нет и CRDT — это наше все.
          0
          При четном количестве голосующих вполне годится стратегия выбора первого варианта.
            0
            или последнего?
              +2
              Нет, именно первого! Такая стратегия, без каких либо вариантов.
                0
                Именно! А ещё у Google в ДЦ всё очень строго с синхронизацией времени, так что данная схема наиболее вероятна.
            +1
            Согласно официальной информации:
            1. «The Spanner servers in each datacenter in turn retrieve their data from the Colossus File System (CFS) [14] in the same datacenter. Unlike Spanner, CFS is not a globally replicated service and therefore Spanner servers will never communicate with remote CFS instances» (источник)
            2. «Storage Software: Colossus… Client-driven replication, ...» (источник)

            Итого разумно предположить, что сам по себе Colossus:
            а. Не поддерживает репликацию между несколькими датацентрами (маловероятно)
            б. Поддерживает асинхронную репликацию в расположенные недалеко друг от друга датацентры с целью DR и не интерактивной аналитики
            То есть вторая часть статьи неточна
              +1
              > Не поддерживает репликацию между несколькими датацентрами (маловероятно)
              Уточните, Вы о репликации critical state (метаданные системы) или о репликации всех данных хранилища?
              Речь о репликации всех данных хранилища в статье и не шла. А способа не синхронизировать critical state в распределенных системах совсем я еще не знаю (если не синхронизировать state, то в конце концов узлы, входящие в распределенную систему, станут независимыми системами).

              > Поддерживает 1) асинхронную репликацию в расположенные недалеко друг от друга датацентры с целью DR и 2) не интерактивной аналитики
              Ничего, из написанного в посте, не противоречит первому утверждению. Про интерактивную аналитику (2-ое утверждение) также упоминания в статье нет.

              > вторая часть статьи неточна
              Поэтому, что 'неточно' по не ясно.)
                +1
                Зачем нужно синхронизировать critical state? Два кластера Colossus просто не знают о существовании друг друга, и знать им об этом не нужно. Посмотрите, например, на архитектуру Spanner (источник). Информация о местоположении находится на уровне location proxies и управляет ей placement driver, то есть это приложениезнает о том, в каком из датацентров находятся какие данные, а не файловая система

                Про синхронизацию внутри пула мастер-серверов не скажу, но для этой задачи вполне подойдет шардинг метаданных по хэшу пути и синхронная master-slave репликация, хотя тут могут быть нюансы
              –3
              Интересно, хотя читать из-за курсива тяжело: мало того, что курсив у шрифта без засечек несколько странно смотрится, так еще и выделяя каждое пятое слово, автор будто тыкает читателя, сбивая обычный тому темп чтения и попросту не доверяя, что читатель способен выбрать в тексте нужные слова.
                0

                Only users with full accounts can post comments. Log in, please.