Я использую простой стек рельсов на одной выделенной машине. Мы вышли на полную мощность и у нас нет абсолютно никакой настройки для масштабирования, только одно приложение на одной машине. Я провел небольшое исследование и придумал потенциальный стек для масштабируемости. Я не профессиональный администратор, но у меня есть несколько мыслей о том, что нам делать с EC2. Я все еще не уверен в совместном использовании файловой системы, и это мой главный вопрос. Во-первых, вот с чем я имею дело.
Текущий стек:
Что делает наше приложение:
Наше приложение выполняет много загрузок изображений и большую обработку изображений с помощью ImageMagick. Он также общается с jaxer для длительных преобразований холста в изображение. Все это отложено. Мы хотели бы, чтобы этот материал особенно масштабировался. Итак, мы говорим о быстрорастущих потребностях в хранении файлов и об интенсивной обработке изображений в фоновых задачах.
Мои решения на данный момент:
Вопросы:
Главный актуальный вопрос: что происходит со всеми файлами? Если я решу разделить роль приложения на несколько экземпляров, как мне получить доступ к общей файловой системе?
Кроме того, было бы здорово услышать некоторые мысли о моей настройке в целом.
Итак, большую часть того, что у вас есть, довольно просто масштабировать. PgSQL на собственном компьютере, чтобы в качестве первого шага избавиться от кучи потребления ресурсов ЦП / диска / ввода-вывода / памяти. Сфинкс тоже в свой маленький мир. Определенно переключитесь в режим восстановления, чтобы облегчить горизонтальное масштабирование ваших рабочих.
Но файлы ... да, файлы сложные. Они всегда трудны. А вариантов у вас очень мало.
Некоторые люди порекомендуют кластерный путь файловой системы, либо волшебную суперкластеризацию (GFS2 / OCFS2), либо немного более бедный вариант чего-то вроде GlusterFS. Я запустил много систем (более 1000) с использованием GFS, и я никогда не Когда-либо сделай это снова. (На самом деле, он может даже не работать в сети EC2). GFS2 / OCFS2 - это беспорядок из движущихся частей, недостаточно документированный, чрезмерно сложный и склонный к сбивающим с толку режимам отказа, которые просто доставляют вам хлопоты во время простоя. Он также не работает ни черта, особенно в среде с большим количеством операций записи - он просто падает, выкидывая весь кластер и требуя 10-30 минут работы на уровне гуру, чтобы снова запустить его. Избегайте этого, и ваша жизнь станет намного проще. Я никогда не запускал GlusterFS, но это потому, что меня это никогда особо не впечатляло. Все, что вы можете с этим сделать, в любом случае есть способ лучше.
На мой взгляд, лучший вариант - это почтенный сервер NFS. Одна машина с большим (или не очень) томом EBS и запущенным демоном NFS, и все его монтируют. У него есть подводные камни (это не действительно файловая система POSIX, поэтому не относитесь к ней как к таковой), но для простой операции «там, я исправил» для 99% случаев использования это неплохо. По крайней мере, это может быть временным препятствием, пока вы работаете над лучшим решением, которое ...
Используйте свои знания о своем приложении для многоуровневого хранения. Это подход, который я использовал совсем недавно (масштабирование Github), и он отлично сработал. По сути, вместо того, чтобы рассматривать файловое хранилище как файловую систему, вы относитесь к нему как к услуге - предоставляете интеллектуальный API для частей вашего приложения, использующих файловое хранилище, чтобы они могли делать то, что вы необходимость делать. В вашем случае вам может потребоваться просто иметь возможность хранить и извлекать изображения с заранее выделенными идентификаторами (например, PK для вашей таблицы «изображений» в БД). Для этого не нужна целая файловая система POSIX, ей просто нужна пара супероптимизированных HTTP-методов (POST-запросы должны обрабатываться динамически, но если вы действительно умный, вы можете сделать так, чтобы GET приходили прямо с диска в виде статических файлов). Черт, вы, вероятно, отправляете эти изображения прямо обратно клиентам, поэтому исключите среднего человека и сделайте этот сервер своим общедоступным сервером ресурсов, пока вы на нем.
Тогда рабочий процесс может выглядеть примерно так:
Вам также не обязательно использовать HTTP POST для размещения изображений на сервере - Github, например, общается со своими файловыми серверами, используя Git-over-SSH, который для них отлично работает. Ключ, однако, состоит в том, чтобы больше обдумать, где должна выполняться работа, и избегать ненужного использования ограниченных ресурсов (сетевой ввод-вывод для запроса сервера NFS), вместо этого торгуя более ограниченным набором вариантов использования ("Вы можете только запрашивать целые файлы атомарно! "), которые работают для вашего приложения.
Наконец, вам нужно будет учитывать фактор масштабируемости. Однако, если вы используете интеллектуальный транспорт, это просто - добавьте (небольшое количество) логику, необходимую для определения того, с каким файловым сервером вам нужно разговаривать в каждом месте, которое общается с файловым сервером, и вы в основном получаете бесконечную масштабируемость. . В вашей ситуации вы можете понять, что ваш первый файловый сервер будет заполнен, скажем, 750 000 изображений. Итак, ваше правило: «Обращайтесь к файловому серверу с именем хоста. fs#{image_id / 750_000}", который нетрудно закодировать везде.
Я всегда получал удовольствие от этой части моей работы ...