Есть ситуации, когда нагрузка сильно увеличивается (о вас написали в New York Times или ссылку ретвитнул супер известный блогер) и на ваш стартап, которому так необходима реклама наваливается огромная толпа долгожданных пользователей. И облачный хостинг как раз и должен решать эту проблему, тут вы правы.
Но что мы будем делать со своим стартапом, когда получим счёт от AWS на 5000$, а у вас всего столько денег на ваш проект. Возможно, было бы дешевле упасть на минут 10, пока вы оформили заказ на 4 дополнительных сервера и запустили Ansible, который их добавит в ваше облако. А оставшиеся 4900$ потратить на рекламу вашего проекта.
Конкретно у меня ситуация такая, что требования к размеру хранилища растут быстрее требований к CPU и оперативной памяти. Получается так, что мне надо например 4 дополнительных сервера только для того, что бы у меня было 24Tb дополнительного места, при этом 4 * 8 = 32 ядра никогда не будут загружены, большая часть из 128Gb оперативной памяти тоже будет свободна.
Решение, кажется, в том, что бы просто доставить жесткие диски в сервера, но выйдет дороже, чем арендовать еще несколько серверов. Каждый новый сервер идет со включенным бесплатным трафиком, который тоже используется по назначению и добавляет 1Gbps к общей пропускной способности.
Я уже писал выше, сколько это может стоить у AWS например. Если взять полученную стоимость, разделить на 3, накупить на эти деньги серверов, то у вас будет очень хороший запас производительности.
Это точно. В самом начале использования Docker'a и при запуске первых версий проекта вообще никаких проблем не было. Но по мере того, как проект начал разбиваться на части, которые зависят друг от друга (вышеупомянутая микросервисная архитектура) + количество машин выросло, все стало уже не так просто и весело.
Пришлось потратить время, что бы вникнуть в возможные решения проблем и только потом начать их постепенно решать.
> вы сделали локальный кластер
Что вы имеете ввиду под словом «локальный»? Частный?
> с балансировкой нагрузки
Я не писал в этой части ничего о балансировке нагрузке, так что её пока нет.
> Но где тут «облачность»?
Сейчас «облачность» заключается в том, что вы можете запустить выполнение вашего веб-приложения, сказав – «Мне надо 512Mb оперативной памяти, SSD диск и MongoDB рядом. Иди выполнись там где-нибудь». И где оно будет выполняться, вы не думаете.
Я уже писал выше, что называть это полноценным облачным хостингом пока нельзя, предстоит написать еще несколько статей и решить массу проблем.
Любая маленькая задумка в моей голове превращается в грандиозный план, который ограничивается только временем моей жизни.
Я хочу написать серию статей, про то, как сейчас у меня все устроено. Открывая занавесу тайны, там и балансировщики нагрузки и Service Discovery c DNS и распределенная файловая система и приватная сеть и т.д. Надо время, что бы разделить все это на части и сформулировать доступным для «не системных администраторов» языком.
То, что есть сейчас называть облачным хостингом нельзя. Но я надеюсь, что это только начало.
Если кластер у вас один или несколько подписанных одним ЦС, а ваша клиенсткая машина хорошо защищена, то да.
У меня все рабочие файла хранятся в зашифрованном образе, который я могу открыть на другой машине, поэтому так. Более того, если я сгенерирую новые сертификаты, то мне надо будет не забыть их обновить и тут. Я для себя решил проблему просто добавив в Makefile:
Я знаком с Docker Machine, он мог бы решить задачу, описанную в этой статье, но не смог бы решить остальные мои задачи о которых я планирую написать в следующих частях.
Сейчас я описал лишь небольшую часть облака и в будущем решение станет более очевидным.
Решил дополнить немного. Большинство ограничений можно обойти, но на практике мы получим низкую производительность. Удалить старые файлы из GridFS мы конечно можем, но больше свободного места мы таким образом не получим. Редактирование файлов можно выполнить вручную (когда-то это можно было делать штатными средствами), но тогда чтение будет не последовательное и мы получим низкую производительность (насколько я помню, именно по этой причине они выпилили эту возможность).
Я отказался от использования GridFS в своем проекте, хотя MongoDB мне нравится. До тех пор, пока размер данных небольшой, я все храню в обычной файловой системе и это, на мой взгляд, самое лучшее решение. Когда встанет вопрос хранения, то я думаю в сторону Ceph FS, но об этом решении надо говорить с тем, кто имел опыт его использования.
Про GridFS можно говорить много, но есть несколько моментов, которые стоит учитывать. Это обычная MongoDB, а GridFS это просто удобный интерфейс для хранения файлов в ней. Запускать MongoDB лучше всего в изолированном окружении, в количестве 2-х экземпляров + арбитр, что привносит доп. расходы. Писать мы можем в нее только последовательно и запись производиться через 1 сервер (если нет шардинга). Если у вас преимущественно чтение, в редких случаях запись, не требуется редактировать или удалить старые файлы, есть возможность выделить ресурсы на запуск нескольких экземпляров MongoDB, то можете рассмотреть этот вариант. В остальных же случаях надо искать другое решиние.
У меня есть понимание, как все эти фреймворки работают. Ну и конечно во время теста была бы видна нагрузка на другие ядра. Так что мой ответ – да, уверенность есть.
Задачей было проверить скорость отдачи файлов с использованием различных фреймворков. Более того, в моем проекте было непонятно где именно будут хранится файлы, в файловой системе или GridFS или еще где-то. Понятно, что в продакшене будут использоваться балансировщик, кеширование, авторизация и прочие моменты и результаты тестов будут другие.
К этому моменту я уже решил, что буду использовать Gevent в своем проекте (в результате получилось не так), а свои сроки на тестирование я уже привысил, поэтому я решил провести сравнение с одним из самых распространенных решений node.js + mongodb.
Я, к сожаленю, уже не смогу получить эту информацию. Исследование я проводил несколько месяцев назад, машин в наличии уже нет, на которых я проводил тест. В любом случае спасибо за вопрос, когда я решу делать еще одно тестирование, я буду знать какую информацию стоит добавить в статью.
Но что мы будем делать со своим стартапом, когда получим счёт от AWS на 5000$, а у вас всего столько денег на ваш проект. Возможно, было бы дешевле упасть на минут 10, пока вы оформили заказ на 4 дополнительных сервера и запустили Ansible, который их добавит в ваше облако. А оставшиеся 4900$ потратить на рекламу вашего проекта.
Конкретно у меня ситуация такая, что требования к размеру хранилища растут быстрее требований к CPU и оперативной памяти. Получается так, что мне надо например 4 дополнительных сервера только для того, что бы у меня было 24Tb дополнительного места, при этом 4 * 8 = 32 ядра никогда не будут загружены, большая часть из 128Gb оперативной памяти тоже будет свободна.
Решение, кажется, в том, что бы просто доставить жесткие диски в сервера, но выйдет дороже, чем арендовать еще несколько серверов. Каждый новый сервер идет со включенным бесплатным трафиком, который тоже используется по назначению и добавляет 1Gbps к общей пропускной способности.
Я уже писал выше, сколько это может стоить у AWS например. Если взять полученную стоимость, разделить на 3, накупить на эти деньги серверов, то у вас будет очень хороший запас производительности.
Пришлось потратить время, что бы вникнуть в возможные решения проблем и только потом начать их постепенно решать.
Что вы имеете ввиду под словом «локальный»? Частный?
> с балансировкой нагрузки
Я не писал в этой части ничего о балансировке нагрузке, так что её пока нет.
> Но где тут «облачность»?
Сейчас «облачность» заключается в том, что вы можете запустить выполнение вашего веб-приложения, сказав – «Мне надо 512Mb оперативной памяти, SSD диск и MongoDB рядом. Иди выполнись там где-нибудь». И где оно будет выполняться, вы не думаете.
Я уже писал выше, что называть это полноценным облачным хостингом пока нельзя, предстоит написать еще несколько статей и решить массу проблем.
Я хочу написать серию статей, про то, как сейчас у меня все устроено. Открывая занавесу тайны, там и балансировщики нагрузки и Service Discovery c DNS и распределенная файловая система и приватная сеть и т.д. Надо время, что бы разделить все это на части и сформулировать доступным для «не системных администраторов» языком.
То, что есть сейчас называть облачным хостингом нельзя. Но я надеюсь, что это только начало.
Трафик: 0,090$ * 1024Mb * 9Tb = 829,44$
= 983,04$/месяц
В указанные ~100$ входят еще 16 честных ядер, 64Gb оперативной памяти, 480Gb SSD и 60Tb трафика, которые я не стал тут добавлять в стоимость.
У меня все рабочие файла хранятся в зашифрованном образе, который я могу открыть на другой машине, поэтому так. Более того, если я сгенерирую новые сертификаты, то мне надо будет не забыть их обновить и тут. Я для себя решил проблему просто добавив в Makefile:
Сейчас я описал лишь небольшую часть облака и в будущем решение станет более очевидным.
Про GridFS можно говорить много, но есть несколько моментов, которые стоит учитывать. Это обычная MongoDB, а GridFS это просто удобный интерфейс для хранения файлов в ней. Запускать MongoDB лучше всего в изолированном окружении, в количестве 2-х экземпляров + арбитр, что привносит доп. расходы. Писать мы можем в нее только последовательно и запись производиться через 1 сервер (если нет шардинга). Если у вас преимущественно чтение, в редких случаях запись, не требуется редактировать или удалить старые файлы, есть возможность выделить ресурсы на запуск нескольких экземпляров MongoDB, то можете рассмотреть этот вариант. В остальных же случаях надо искать другое решиние.