Извините, сейчас будет дурацкая идея :)
Наверняка можно найти современный remote desktop client(что то типа team viewer) который имеет web клиента. Идея в том, чтобы коннектится на локальную машинку через него, и в нем как бы скринить сублайм.
Второй пример в директиве (с именованным локейшеном) делает ровно то, что вам нужно. И без всяких извращений с try_files как советуют здесь выше и ниже.
Закономерности нет, есть как бы взаимосвязь, но прямой зависимости нет, потому что все зависит от того куда на диске пишутся данные.
Чуть ниже ответ amarao и его пояснения на мои вопросы, это тоже неплохой объективный способ оценки общей загрузки диска.
r10k который Вы упомянул ниже сложен для понимания, когда начинаешь "пробовать" паппет в первый раз. После того как осваиваешься и появляются более конкретные пожелания к системе, становится понятно что к чему.
Моему примеру предшествует комментарий "Вы всегда можете нагородить", я надеялся что это даст понять человеку то что это не очень правильное решение но допустимое в критичных ситуациях.
Мы живем кстати без r10k с 2мя ветками всего лишь. И норм. А для тестов есть тестовое окружение на проекте, которое используется не только разработчиками для тестирования но и админами.
Ansible создал разраб cobbler а не паппета.
Ансибл уступает скоростью развертывания, аналогичный плейбук паппетом раскатывается быстрее, а повторные чеки вообще не стоит сравнивать.
Поясните пожалуйста.
К примеру у нас диск имеет random read 3ms. Мы снимаем значение flight_time и в определенный момент времени наблюдаем это значение высоким, поскольку данный параметры описывает фактически кол-во незавершенных операций. В свою очередь, эти операции могут укладывать во временные рамки 3ms и завершаться пропадая из очереди, а их появление вызвано "микросатурейшеном"
Тоесть мы можем наблюдать ситуацию когда у нас и await и svctm не превышает 3ms но в свою очередь значение flight_time высокое ?
Нет не работает, дело как раз в том, что в случае необходимости расширения дискового пространства, выходит дешевле. У Kimsufi не стабильно с наличием машин и с подходящими конфигурациями, по факту дешевые варианты это сейлы старых машин которые то бывают то нет.
У RunAbove дешевый object storage который swift compatible, на гитхабе можно найти от rackspace fuse драйвер для swift. Но честно говорят не пробовал, нужно экспериментировать и тестировать.
hbrmdc: Вы так пишите, будто "язык" это что то важное, в случае написания ПО. Скорее важно умение грамотно писать этот код, знание каких то правильных подходов написания тех или иных систем (системы для конечного пользователя, распределенные системы, сложные математические алгоритмы).
По факту вижу что опытные разработчики могу качественно писать на 2-3 языках, но лишь в одной специфике задач.
Наверно меня смутило слово "масштабирование". Как вы собрались масштабироваться в рамках одной машины ? разложить партиции по разным дискам дабы ускорить чтение\запись ? Нет, у монги ничего такого нет.
Станислав Макаров Все что Вы описываете можно свести к нескольким простым принципам.
1. Все ноды в "кластере" образуют хешринг, разбитый на диапазоны хэшей.
2. Каждая нода в кластере "держит" некую группу этих диапазонов, и желательно последовательную.
3. При добавлении новой ноды, мы выбираем некий объем данных (скажем 100Гб) и исходя из объема пространства выделенного под хранение, формируем N хешей (конечных точек диапазонов).
4. "Таблица маршрутизации" для операций чтения / записи, представляет собой хэш таблицу, где в качестве ключа используется конечные значения хэшей всех диапазонов, а в качестве значения имя ноды.
Т.о. как сайд эффект, в случае выпадения одной из нод, мы получаем "запись" на другую ноду. Но мы без проблем можем осуществлять "скан" соседних узлов, и осуществлять восстановление данных если были проблемы.
5. Для того чтобы не было таких проблем мы можем "задублировать" наше кольцо еще одной такой же группой. В случае возникновения ошибок чтения/записи, мы можем обращаться в эту реплику и с нее производить восстановление данных + сами операции. В качестве позитивного сайд эффекта здесь видится реализация групп с "горячим контентом" и с "устаревшим контентом" в случае необходимости.
Но все это велосипеды. Так работают leo/elliptics.
Решения ceph и подобные имеют альтернативный способ решения проблем: у них есть централизованные ноды хранящие метаданные. Это может быть проще в эксплуатации и первичной реализации, но минусом будет сложность реализации которая бы давала приличную скорость работы с самими данными, поскольку любая операция с ними будет требовать обновления этих метаданных. Если мы начнем говорить о том что наше "облако" гео распределенное, всплывает вопрос консистентности и еще более сложная ее реализация.
Поэтому я и призываю не "велосипедить", а изучить те решения что есть и выбрать подходящее. 2 года назад я столкнулся с такой задачей, потратил порядка 2 месяцев на выбор и тестирование различных решений. И время было потрачено не зря. Сейчас, оглядываясь на те очень тонкие проблемы с которыми мы столкнулись в эксплуатации, мне даже страшно представить с каким бы объемом других более явных проблем (которые просто не замечаешь, пока не прочитаешь архитектурную документацию по стораджам), мы могли бы столкнуться, если бы начали сами "велосипедить".
Я посмотрел :) Но мне кажется изначально ущербным такое оправдание : "Не знаю где вы в этом разговоре увидели что я утверждал что мой вариант хотя бы жизнеспособен". Искренне не понимаю, зачем вообще предлагать нежизнеспособные варианты.
