В рамках миграции локальные диски переносятся сами. Но в рамках инцидента, когда упал сервер, мы на какое-то время теряем эти диски, да.
Возможно, я плохо объяснил, почему это не надо на самом деле. Когда вы строите отказоустойчивые приложения, вы должны допускать такой вариант отказа, что у вас какой-то датацентр станет недоступным. Соответственно, решать этот вариант отказа можно двумя способами - растягивать сетевые диски между ЦОДами, либо на уровне приложения обеспечивать отказоустойчивость и необходимую репликацию. В реальной жизни допустимый вариант только второй, потому что сетевые диски растянутые между ЦОДами будут работать очень медленно, да еще и стоимость такого решения будет огромной из-за каналов связи, которые вам нужно будет иметь. Соответственно, если вы умеете переживать отказ одного дц без какого-то влияния на приложение, то любой отказ конкретного сервера внутри дц - это частный случай более сложной ситуации, с которой вы уже умеете справляться.
Мне кажется, что порой люди переоценивают страх разработки своего и недооценивают риски использования чего-то из индустрии. Мы все видим большое количество компаний, которые пишут свои продукты, а по сути свой продуктовый софт это такой же вендор-лок на свою команду разработки, со всеми вытекающими рисками. В этом плане инфраструктурная разработка очень слабо отличается от продуктовой. При этом есть еще другой аспект - использование чего-то из opensource не гарантирует, то, что бизнес не получит вендор-лок на команду эксплуатации. Особенно, если масштаб использования технологий очень большой. Найти сильного DBA для очень популярной PostgreSQL совсем не просто, или, например, найти людей, которые выстраивали успешную эксплуатацию кластеров ceph-а размером в петабайты и десятки петабайт очень и очень сложно.
Если я правильно понял вопросы, то ответы следующие:
Железок у нас в эксплуатации "высокие" сотни. Может я недостаточно ясно выразился в статье, но основной наш код это как раз клей между текущими opensource решениями такими как kvm/qemu/ovn/ovs/итд. Да, в опенстек можно много чего прикрутить. Я лично под большим впечатлением от опыта эксплуатации одной крупной компании, которая и замену нейтрона пишет, и замену trove и много чего еще делает.
Да, такие риски обоснованы и всегда есть. Но начиная с определенных объемов инфраструктуры потенциальная экономия начинает превосходить риски. Надо еще учесть, что условный OpenStack - это не зеленый луг с бабочками. Мы, конечно, же общались с коллегами из других компаний, которые эксплуатируют такие решения и учитывали их опыт.
Вообще однозначного ответа и серебряной пули в этом вопросе нету - есть и примеры условных покупок vmware/huawei с последующими проблемами с уходом вендоров, есть успешные примеры разработки и эксплуатации собственных технологий в индустрии, но есть и примеры неудачных собственных разработок.
У нас в компании сформировался уже технологический стек - stateless нагрузки мы запускаем в k8s (кажется, что их у нас уже сотни), а statefull, вроде баз данных, очередей и прочих приложений, в виртуальных машинах. Заставлять пользователей менять технологии, которые они используют == иметь большие сложности в внедрении.
Простой вопрос, и сложный ответ - у нас есть терраформ провайдер, написанный коллегами из другого отдела, и есть провайдер, который написал наш отдел, но мы его еще не опубликовали внутри (требуются кое какие доработки).
Привет. Спасибо за комментарий. Давайте по порядку.
У проекта была относительно сложная судьба - до релиза он несколько раз переписывался. Ну, наверное, последняя итерация разработки релизной версии заняла около года, причем достаточно маленькой командой - около 10 человек.
Пока что для наших собственных целей мы не хотим использовать SDS - кажется, что это очень недешевая технология, которая при этом решает достаточно мало наших проблем. И эти проблемы нам дешевле решать другим способом.
Да, про GPU был заход, но пока что не очень успешный - в рамках нашего облака пока что нет такого сервиса. Но вообще в компании есть достаточно много использования GPU, просто не в рамках нашего продукта. Ну а публичными облаками мы стараемся не пользоваться.
С исключениями в V8 надо быть очень осторожными. Разработчики из гугла на одной из конференций говорили, что движок очень плохо оптимизирует код в try { } блоке. Поэтому лучше оборачивать в try-catch только те куски кода, где действительно может появится исключения.
По алгоритму нагла можно почитать тут — en.wikipedia.org/wiki/Nagle's_algorithm
Если коротко, то это дополнительная буферизация, которая дает выигрыш, если приложение часто отправляет маленькие куски данных по сети. Это будет работать в том случае, если вы отправляете постоянно данные в сокет размером заметно меньшим половине MTU (в этом случае несколько пакетов можно отправить один TCP-пакетом и сэкономить на передаче заголовков TCP-пакетов). В случае HTTP-сервера этот алгоритм не имеет смысла использовать.
Смотря, какой клиент у вас будет. На node.js очень легко и просто написать TCP или UDP сервер. Все зависит от того, что у вас будет в роли клиента. Если вы собираетесь реализовать клиент на HTML5, то надо смотреть на уровень поддержки бинарных сокетов в Websocket, так как текстовый протокол передачи данных будет съедать оень много ресурсов. На стороне ноды есть удобные абстракции, чтобы вычитывать бинарные данные из сокета и разбирать полученные буферы. В этом плане node.js намного-намного круче, чем php :-)
Если вы реализуете реалтайм соединение, то перед вами под нагрузкой опять же станет проблема сборщика мусора на сервере, который может останавливать сервер на десятки или сотни мс, что для реалтайм шутера недопустимо. Но, в принципе, можно обойти и этот момент. Навскидку, я бы реализовал это так — надо иметь пул серверов под процессы, которые обрабатывают сами игры (если они будут сделаны как в CS или Quake). В каждом из таких процессов можно подавить сборку мусора, задав определенный флаг на запуске, ну и написать код таким образом, чтобы он не тек. Заканчивается раунд в игре — процесс убивается.
Все зависит от требования к real-time и к логике игры. Если у вас очень сложная логика, которая может потребовать ресурсоемких вычислений — то это не ваш выбор. У node.js есть сильное ограничение в виде однопоточности, то есть вы выполнением каких-нибудь сложных расчетов можете заблокировать полностью весь процесс. Плюс еще на больших нагрузках, когда приложение создает много различных объектов, garbage collector может долго отрабатывать. У меня после оптимизаций в тестах на 5к rps паузы достигали 200мс. Но с каждым релизом сборщик мусора становится все лучше и лучше. Свои тесты я проводил на версии 0.6 (сейчас актуальна ветка 0.8).
У меня сложилось ощущение, что node.js это отличный вариант для REST-сервисов с достаточно простой логикой. Так же стоит учесть, что нет возможности запустить приложение в несколько потоков с общей памятью, но в то же время можно запускать приложение в несклько процессов и обмениваться между ними сообщениями.
Кстати, не так давно mozilla выпустила браузерную realtime игру, клиент которой написан на HTML5, а сервер — на node.js. Называется — BrowserQuest. Исходники на гитхабе — github.com/mozilla/BrowserQuest
Честно признаться, не силен в клиентском яваскрипте. Работал давно на стороне клиента.
Точно могу сказать, что на сервере надо больше внимания обработке ошибок. Механизм исключений использовать для асинхронного кода нельзя вообще — только событий или коллбеки с передачей ошибок. Так же нельзя вообще писать код, который может заблокировать event-loop. Никакого кода, который требует много процессорных ресурсов в основном процессе приложения.
Но даже с моим опытом клиентского JS, могу точно сказать, что серверый JS это совсем другой язык. Самое главное преимущество — код исполняется только в одной среде и ты точно знаешь какие языковые конструкции поддерживаются. На самом деле возможности языка поражают, его сила на клиенте очень и очень недооценена. Все то, что делается в браузере при помощи underscore, есть в самом языке.
Я перешел на node.js потому, что срочно потребовалось написать приложение, поддерживающее сокеты, а не http. Ни с connect, ни с express не работал. Был опыт работы с socket.io, но в итоге для нового проекта я решил реализовать самому long-polling.
Не пробовал. Сейчас у меня все сервера крутятся на Amazon EC2. Честно сказать, я даже и не могу представить, как можно запускать Node.JS на GAE. GAE — это же по сути услуга сервиса запуска python и Java приложений. Нативной поддержки Node.JS там нет.
Если я не ошибаюсь, то у вас в реализации существует серьезная уязвимость. При проверке существует ли метод в теле вы не проверяете входные переменные.
Например, при попытке вызова такого URL-а, для существующего контроллера: www.example.com/api/?apitest.getApiEngineByName=test будет заинклуден файл test.php.
А если еще включена настройка allow_url_fopen, то можно будет вообще загрузить и подключить какой-нибудь шелл.
В рамках миграции локальные диски переносятся сами. Но в рамках инцидента, когда упал сервер, мы на какое-то время теряем эти диски, да.
Возможно, я плохо объяснил, почему это не надо на самом деле. Когда вы строите отказоустойчивые приложения, вы должны допускать такой вариант отказа, что у вас какой-то датацентр станет недоступным. Соответственно, решать этот вариант отказа можно двумя способами - растягивать сетевые диски между ЦОДами, либо на уровне приложения обеспечивать отказоустойчивость и необходимую репликацию. В реальной жизни допустимый вариант только второй, потому что сетевые диски растянутые между ЦОДами будут работать очень медленно, да еще и стоимость такого решения будет огромной из-за каналов связи, которые вам нужно будет иметь. Соответственно, если вы умеете переживать отказ одного дц без какого-то влияния на приложение, то любой отказ конкретного сервера внутри дц - это частный случай более сложной ситуации, с которой вы уже умеете справляться.
Спасибо за комментарий. Очень верно подмечено.
Мне кажется, что порой люди переоценивают страх разработки своего и недооценивают риски использования чего-то из индустрии. Мы все видим большое количество компаний, которые пишут свои продукты, а по сути свой продуктовый софт это такой же вендор-лок на свою команду разработки, со всеми вытекающими рисками. В этом плане инфраструктурная разработка очень слабо отличается от продуктовой.
При этом есть еще другой аспект - использование чего-то из opensource не гарантирует, то, что бизнес не получит вендор-лок на команду эксплуатации. Особенно, если масштаб использования технологий очень большой. Найти сильного DBA для очень популярной PostgreSQL совсем не просто, или, например, найти людей, которые выстраивали успешную эксплуатацию кластеров ceph-а размером в петабайты и десятки петабайт очень и очень сложно.
Если я правильно понял вопросы, то ответы следующие:
Железок у нас в эксплуатации "высокие" сотни.
Может я недостаточно ясно выразился в статье, но основной наш код это как раз клей между текущими opensource решениями такими как kvm/qemu/ovn/ovs/итд.
Да, в опенстек можно много чего прикрутить. Я лично под большим впечатлением от опыта эксплуатации одной крупной компании, которая и замену нейтрона пишет, и замену trove и много чего еще делает.
Да, такие риски обоснованы и всегда есть.
Но начиная с определенных объемов инфраструктуры потенциальная экономия начинает превосходить риски. Надо еще учесть, что условный OpenStack - это не зеленый луг с бабочками. Мы, конечно, же общались с коллегами из других компаний, которые эксплуатируют такие решения и учитывали их опыт.
Вообще однозначного ответа и серебряной пули в этом вопросе нету - есть и примеры условных покупок vmware/huawei с последующими проблемами с уходом вендоров, есть успешные примеры разработки и эксплуатации собственных технологий в индустрии, но есть и примеры неудачных собственных разработок.
У нас в компании сформировался уже технологический стек - stateless нагрузки мы запускаем в k8s (кажется, что их у нас уже сотни), а statefull, вроде баз данных, очередей и прочих приложений, в виртуальных машинах. Заставлять пользователей менять технологии, которые они используют == иметь большие сложности в внедрении.
Простой вопрос, и сложный ответ - у нас есть терраформ провайдер, написанный коллегами из другого отдела, и есть провайдер, который написал наш отдел, но мы его еще не опубликовали внутри (требуются кое какие доработки).
Привет. Спасибо за комментарий. Давайте по порядку.
У проекта была относительно сложная судьба - до релиза он несколько раз переписывался. Ну, наверное, последняя итерация разработки релизной версии заняла около года, причем достаточно маленькой командой - около 10 человек.
Пока что для наших собственных целей мы не хотим использовать SDS - кажется, что это очень недешевая технология, которая при этом решает достаточно мало наших проблем. И эти проблемы нам дешевле решать другим способом.
Да, про GPU был заход, но пока что не очень успешный - в рамках нашего облака пока что нет такого сервиса. Но вообще в компании есть достаточно много использования GPU, просто не в рамках нашего продукта. Ну а публичными облаками мы стараемся не пользоваться.
Если коротко, то это дополнительная буферизация, которая дает выигрыш, если приложение часто отправляет маленькие куски данных по сети. Это будет работать в том случае, если вы отправляете постоянно данные в сокет размером заметно меньшим половине MTU (в этом случае несколько пакетов можно отправить один TCP-пакетом и сэкономить на передаче заголовков TCP-пакетов). В случае HTTP-сервера этот алгоритм не имеет смысла использовать.
Если вы реализуете реалтайм соединение, то перед вами под нагрузкой опять же станет проблема сборщика мусора на сервере, который может останавливать сервер на десятки или сотни мс, что для реалтайм шутера недопустимо. Но, в принципе, можно обойти и этот момент. Навскидку, я бы реализовал это так — надо иметь пул серверов под процессы, которые обрабатывают сами игры (если они будут сделаны как в CS или Quake). В каждом из таких процессов можно подавить сборку мусора, задав определенный флаг на запуске, ну и написать код таким образом, чтобы он не тек. Заканчивается раунд в игре — процесс убивается.
У меня сложилось ощущение, что node.js это отличный вариант для REST-сервисов с достаточно простой логикой. Так же стоит учесть, что нет возможности запустить приложение в несколько потоков с общей памятью, но в то же время можно запускать приложение в несклько процессов и обмениваться между ними сообщениями.
Кстати, не так давно mozilla выпустила браузерную realtime игру, клиент которой написан на HTML5, а сервер — на node.js. Называется — BrowserQuest. Исходники на гитхабе — github.com/mozilla/BrowserQuest
Точно могу сказать, что на сервере надо больше внимания обработке ошибок. Механизм исключений использовать для асинхронного кода нельзя вообще — только событий или коллбеки с передачей ошибок. Так же нельзя вообще писать код, который может заблокировать event-loop. Никакого кода, который требует много процессорных ресурсов в основном процессе приложения.
Но даже с моим опытом клиентского JS, могу точно сказать, что серверый JS это совсем другой язык. Самое главное преимущество — код исполняется только в одной среде и ты точно знаешь какие языковые конструкции поддерживаются. На самом деле возможности языка поражают, его сила на клиенте очень и очень недооценена. Все то, что делается в браузере при помощи underscore, есть в самом языке.
Например, при попытке вызова такого URL-а, для существующего контроллера:
www.example.com/api/?apitest.getApiEngineByName=test будет заинклуден файл test.php.
А если еще включена настройка allow_url_fopen, то можно будет вообще загрузить и подключить какой-нибудь шелл.