Здесь я говорю об облачных серверах (от любого поставщика), которые имеют некоторое количество временного хранилища SSD. При работе со стандартными образами по умолчанию это временное хранилище SSD тратится и не используется.
При развертывании стека LAMP на таких виртуальных машинах, каковы очевидные способы использования временного хранилища SSD?
Очевидный пример - поместить файл подкачки и / tmp в эфемерный.
Что еще такое низко висящий фрукт? Вещи настолько очевидны, что пропустит только некомпетентный системный администратор?
/tmp и своп действительно являются очевидным низко висящим плодом.
Я полагаю, что все остальное, что я могу придумать, в значительной степени зависит от конкретного приложения.
Либо так, либо мы с вами оба сравнительно некомпетентные системные администраторы, поскольку оба упускаем из виду нечто очевидное.
Эфемерное хранилище является бесплатным и быстрым и выдерживает перезагрузку экземпляра, инициированную пользователем, поэтому на самом деле все, что в конечном итоге является «одноразовым», может быть (автоматически) поставлено туда из другого места (возможно, клонировано из репозитория кода или извлечено из архива, хранящегося в S3) когда экземпляр запущен или иным образом получен из своего источника.
Когда вы полностью "мыслящее облако", многие будут утверждать, что практически все на многих или большинстве серверов должно быть одноразовым ... Я бы предположил, что многие или большинство из нас признают, что эта тенденция существует, но только на нашем пути к ней - мы еще не сделали этого. т полностью прибыл.
Если ваши системные журналы собираются удаленно, возможно, ваши локальные системные журналы могут перейти на временный диск. То же самое касается журналов веб-сервера или прокси, когда содержимое журналов не считается особенно ценным или вы собираете их в основном только потому, что можете.
Говоря «просто потому, что вы можете», в одном случае у меня есть устаревший сервер с массивом SAN в физическом центре обработки данных, с большим пулом статических ресурсов, которые в конечном итоге будут перенесены на S3. До тех пор, в дополнение к запланированному резервному копированию, файлы также синхронизируются с временными дисками в некоторых случаях, когда временные диски не имеют особо четкого использования. Они служат в качестве резервных онлайн-копий, и в случае чего-то катастрофического будет гораздо быстрее, чем восстановление из резервной копии.
У нас есть приложение, которое создает солидный индекс SOLR полностью с нуля (из других источников) два раза в день, а затем отправляет его на главный сервер. Это не «временное» пространство в классическом понимании, но да, оно построено на эфемерном диске.
Одна из моих установок сервера промежуточной базы данных приходит на ум как пример для конкретного приложения ... она используется только для тестирования кода на клоне производственной базы данных. Все резервное хранилище MySQL находится на временном диске. Я настроил сценарий инициализации так, чтобы "sudo service mysql resync" останавливает демон сервера MySQL, перемещает текущий каталог в сторону (переименовывает его с указанием даты и времени в имени файла), копирует (из EBS) резервное хранилище нового Установка MySQL, символические ссылки /usr/local/mysql/data в новый временный каталог, запускает MySQL, извлекает живую копию производственной базы данных, загружает ее ... и у разработчика теперь есть идентичный клон производственной базы данных ... который, конечно, является одноразовым, поскольку он сразу "устарел" "и используется только для тестирования кода. Если вы запускаете новый из них из AMI, он просыпается, понимая, что у него нет базы данных, и сразу же берет новую копию master db.
Другим сценарием может быть кластерная база данных, где все узлы имеют копию всех данных и работают как кворум (например, MariaDB Galera Cluster). Таким кластерам, особенно когда они географически распределены, необходимо правильно выбранное (обычно нечетное) количество узлов при нормальной работе, потому что весь кластер станет недоступным в качестве защитной меры в случае изоляции (разбиения), если еще не существует единственного раздела, который содержит более половины количества узлов, которые были в сети до того, как произошло разделение. Кластер с двумя или четырьмя узлами становится бесполезным при разделении пополам, поскольку не остается большинства. Иногда это решается с помощью узла «арбитр», который голосует в кворуме, но фактически не имеет копии данных. Все его существование направлено на то, чтобы кластер оставался счастливым. Сделайте еще один шаг и эффективно используйте эфемерное хранилище на этом узле, сделав его полным узлом, предоставив ему полную копию данных, а не просто сделав его арбитром.
Потенциально интересная идея может заключаться в объединении эфемерного тома с томом EBS в конфигурации RAID-1. В зависимости от того, кому вы верите, при одновременном чтении нескольких файлов существует вероятность почти удвоения количества операций ввода-вывода при чтении.
Я боюсь, что с этим ответом я несколько сильно отклонился в землю DBA, но это те вещи, для которых я использую эфемерные тома в моем мире ... помимо очевидного, которое вы уже определили.