В стеке LAMP какие очевидные способы использовать временное хранилище SSD? [закрыто]

/ tmp и своп действительно является очевидным низко висящим плодом.

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

Либо это, либо мы с вами оба сравнительно некомпетентные системные администраторы, поскольку мы оба упускаем из виду нечто очевидное.

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

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

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

Говоря о «просто потому, что вы можете», в одном случае я иметь унаследованный сервер с массивом SAN в физическом центре обработки данных с большим пулом статических ресурсов, которые в конечном итоге будут перенесены на S3. До тех пор, в дополнение к запланированному резервному копированию, файлы также синхронизируются с временными дисками в некоторых случаях, когда временные диски не имеют особо четкого использования. Они служат в качестве резервных онлайн-копий и в случае чего-то катастрофического будут гораздо быстрее запущены, чем восстановление из резервной копии.

У нас есть приложение, которое создает существенный индекс SOLR полностью с нуля (из других источников) два раза в день, затем отправляет его на главный сервер. Это не «временное» пространство в классическом понимании, но да, оно построено на эфемерном диске.

Одна из моих установок сервера промежуточной базы данных приходит на ум как пример для конкретного приложения ... она используется только для тестирования кода на клоне производственной базы данных. Все резервное хранилище MySQL находится на временном диске. Я настроил сценарий инициализации так, чтобы "sudo service mysql resync" останавливает демон сервера MySQL, перемещает текущий каталог в сторону (переименовывает его с указанием даты и времени в имени файла), копирует (из EBS) резервное хранилище нового Установка MySQL, символические ссылки / usr / local / mysql / data в новый временный каталог, запускает MySQL, извлекает живую копию производственной базы данных, загружает ее ... и теперь у разработчика есть идентичный клон производственная база данных ... которая, конечно же, является одноразовой, поскольку она сразу "устаревает" и используется только для тестирования кода. Если вы запускаете новый из них из AMI, он просыпается, понимая, что у него нет базы данных, и сразу же берет новую копию master db.

Другим сценарием может быть кластерная база данных, где все узлы имеют копию всех данных и работают как кворум (как MariaDB Galera Cluster). Таким кластерам, особенно когда они географически распределены, необходимо правильно выбранное (обычно нечетное) количество узлов при нормальной работе, потому что весь кластер станет недоступным в качестве защитной меры в случае изоляции (разбиения), если только не существует единственного раздела, который содержит более половины количества узлов, которые были в сети до того, как произошло разделение. Кластер с 2 узлами или кластер с 4 узлами становится бесполезным при разделении пополам, поскольку не остается большинства. Иногда это решается с помощью узла «арбитр», который голосует в кворуме, но фактически не имеет копии данных. Все его существование направлено на то, чтобы кластер был счастлив. Сделайте еще один шаг и эффективно используйте эфемерное хранилище на этом узле, сделав его полным узлом, предоставив ему полную копию данных вместо того, чтобы просто сделать его арбитром.

Потенциально интересная идея могла бы включать объединение эфемерного хранилища. том с томом EBS в конфигурации RAID-1. В зависимости от того, кому вы верите, при одновременном чтении нескольких файлов существует вероятность почти удвоения количества операций ввода-вывода при чтении.

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