В прошлогоднем обзорном посте, посвященном архитектуре Evernote, мы дали общее описание серверов — “шардов”, которые используем и для хранения данных и для логики приложений. Поскольку Evernote — более персональный сервис, чем, скажем, социальная сеть, то мы можем легко разнести данные отдельных пользователей по различным шардам, чтобы обеспечить достаточно простую линейную масштабируемость. Каждая пара таких шардов управляет двумя виртуальными машинами:
Каждая из этих виртуальных машин хранит транзакционные “метаданные” в базе данных MySQL на массиве RAID-1 из пары 300-гигабайтных дисков Cheetah со скоростью вращения шпинделя 15000 rpm. Отдельный массив RAID-10 из 3-терабайтных дисков Constellation (7200 rpm) разбит на разделы для хранения больших файлов текстового поискового индекса Lucene для каждого пользователя. Спаренные виртуальные машины дублируют каждый из этих разделов от текущей основной к текущей дополнительной машине с помощью синхронного DRBD.
Эти шарды имеют достаточно дискового пространства и поддержку операций ввода/вывода для комфортной обработки данных 100 000 зарегистрированных пользователей Evernote как минимум на 4 года, а также снабжены дополнительными отсеками для дисков в корпусах 4U, чтобы была возможность позднее апгрейдить их при необходимости. С учетом двойных процессоров L5630 и 48 гигабайт оперативной памяти стоимость каждого такого блока составляет до $10 000 с энергопотреблением около 374 ватт каждый. То есть на одного зарегистрированного пользователя приходится около $0,10 расходов на аппаратное обеспечение и 3,7 милливатт энергорасходов.
Возможности для совершенствования
Описанное выше поколение шардов дало нам хорошее соотношение цены и производительности с очень высоким уровнем избыточности данных, которое нам необходимо. Однако мы нашли несколько областей, где эта конфигурация не была идеальной для наших целей. Например:
- Диски с 15000 rpm для базы данных MySQL обычно простаивают 95% времени, с тех пор как InnoDB стало отлично справляться с сериализацией кэширования и операций ввода/вывода. Однако мы обнаружили случайные узкие места, когда пользователи с большими аккаунтами начинают первичную синхронизацию данных на новом устройстве. Если их метаданные еще не присутствуют в буфере оперативной памяти, то массивные операции ввода/вывода могут стать очень затратными.
- Поисковые индексы Lucene для наших пользователей генерируют гораздо больше операций ввода/вывода, чем мы ожидали. Мы видим, что на долю Lucene приходится в два раза больше операций чтения/записи, чем на MySQL. Во многом это обусловлено нашей моделью использования: каждый раз при создании или редактировании заметки нам нужно обновлять индекс ее владельца и отправлять информацию об изменениях на диск, чтобы они немедленно вступили в силу.
- DRBD отлично подходит для репликации одного или двух небольших разделов, но он очень неудобен, когда речь идет о значительном числе больших разделов для каждого сервера. Каждый раздел нужно независимо сконфигурировать, управлять им и проводить мониторинг. Различные проблемы иногда могут потребовать полной синхронизации всех ресурсов, что грозит занять много часов даже при наличии выделенного кроссовер-кабеля с пропускной способностью 1 Гб/c.
Эти ограничения были основным фактором, ограничивающим число пользователей, которое мы могли назначить каждому шарду. Улучшение управляемости и производительности операций ввода/вывода с метаданными позволило бы нам безопасно повысить плотность размещения пользовательских аккаунтов. Мы решаем эти проблемы в нашем новом поколении шардов, переводя хранение метаданных на твердотельные накопители, а логику избыточного объема файлового хранилища из операционной системы в наше приложение.
Новая конфигурация
Наша новая конфигурация заменяет стеллажи с десятком серверов 4U стойками, где вместе находятся четырнадцать шардов 1U для метаданных и приложения и четыре сервера 4U для файлового хранилища.
Шард 1U управляет парой более простых виртуальных машин, каждая из которых использует один раздел на отдельном массиве RAID-5 из твердотельных накопителей Intel на 300 Гб. Эти два раздела реплицируются с помощью DRBD, и образ виртуальной машины работает в один момент времени только на одном сервере. Мы используем до 80% емкости твердотельных накопителей, что заметно повышает надежность записи и пропускную способность для операций ввода/вывода. Мы включили запасной SSD для каждого блока вместо того, чтобы использовать RAID-6, что позволило избежать дополнительной потери до 15% производительности, так как время восстановление будет коротким, и репликация с DRBD даст нам возможность подстраховаться в случае гипотетического отказа нескольких дисков.
Файловое хранилище переведено с локальных дисков на главных серверах в пулы отдельных серверов WebDAV, управляющих огромными файловыми системами на массивах RAID-6.
Всякий раз при добавлении файла ресурса в Evernote наше приложение синхронно записывает копию этого файла на два разных файловых сервера в одной стойке до того, как будет выполнена транзакция метаданных. Удаленное выполнение принципа избыточности также гарантируется приложением, которое реплицирует каждый новый файл на удаленный сервер WebDAV через асинхроннную передачу данных в фоновом режиме.
Результаты
Эта новая конфигурация имеет достаточно емкости для операций ввода/вывода и памяти, чтобы обрабатывать до 200 000 пользователей на одном шарде как минимум в течение четырех лет. Стойка из 14 шардов и 4 файловых серверов стоит около 135 тысяч долларов и потребляет 3900 ватт, что составляет около $0,05 и 1,4 милливатта в перечсете на одного пользователя.
Таким образом, удельное количество будущих серверов и энергопотребление сократилось для новых серверов на 60%. Удельная потребляемая мощность прочего сервисного оборудования (коммутаторы, маршрутизаторы, балансировщики нагрузок, серверы распознавания текста в изображениях и т. д.) снизилась в общей сложности на 50% по сравнению с нашей прежней архитектурой. Все эти изменения снижают наши расходы на в долгосрочной перспективе.
Мы бы не хотели делать громких экологических заявлений [а ведь можно было бы в качестве КДПВ вставить фотографию Фила Либина, обнимающего пушистого белька], но можно отметить, что это 50-процентное снижение энергопотребления пропорционально снижает углеродные выбросы в атмосферу от нашего оборудования.
Помимо явной экономии процесс оценки и тестирования решений позволяет нам более глубоко понимать компоненты и технологии, которые мы используем. Мы планируем написать еще несколько постов, посвященных деталям тестирования и оптимизации RAID-массивов из SSD, сравнительной оценки Xen и KVM с точки зрения пропускной способности ввода/вывода, управлению DRBD и т. д. Мы надеемся, что эта информация окажется полезна нашим коллегам при создании высоконагруженных сервисов.
Автор: Roberto
