Comments 25
Я не использовал Azure, но неужели там нельзя установить на систему FRE, сделать из этого образ, и новые ноды поднимать, используя уже его?
нет, там идея в том, что у вас PaaS, а описанный вариант — это простая виртуалка, как EC2 в Амазоне.
Ажур же настаивает на том, чтобы вы весь ваш продукт сделали в виде некоторого автоматического инсталлятора. И тогда ставить его на любую машину ажур будет самостоятельно.
Ажур же настаивает на том, чтобы вы весь ваш продукт сделали в виде некоторого автоматического инсталлятора. И тогда ставить его на любую машину ажур будет самостоятельно.
Можно, это IaaS-модель использования (как в Amazon EC2). В этом случае при изменениях кода сервиса придется перезаливать этот образ. PaaS-модель в этом плане удобнее — в пакет складываются только часто изменяемые небольшие части сервиса, гораздо меньше заливать вручную. Плюс при использовании PaaS-модели гораздо удобнее масштабирование. Всегда какой-то компромисс.
Это проблема, если держать сервис вшитым в образ. Если использовать модель деплоя сервиса при старте, то, мне кажется, это решит проблему. Именно так делали мы:
1. Собирали образ со всеми библиотеками, настройками, app-сервером
2. При старте сервиса загружали архив с кодом и уже его разворачивали.
Возможен другой вариант, когда деплой делается тем актором, который запускает инстанс.
1. Собирали образ со всеми библиотеками, настройками, app-сервером
2. При старте сервиса загружали архив с кодом и уже его разворачивали.
Возможен другой вариант, когда деплой делается тем актором, который запускает инстанс.
Да, так тоже можно. По сути PaaS в Azure работает аналогично — берется «эталонный» образ, с него запускается виртуальная машина, потом на нее копируется пакет с кодом, код запускается в служебном процессе. Важное преимущество Azure в том, что Azure, например, умеет по очереди отключать виртуальные машины для обновления ОС, потом возвращать их.
Вы ниже писали, что проблемы при обновлении не покрываются SLA. Так что это не обязательно преимущество.
Особо смысла нет в споре IaaS vs PaaS. Везде свои преимущества, главное выбирать наиболее подходящий вариант для конкретного проекта. Но в каждом из подходов надо правильно «готовить» образ, пакет и т.д.
Особо смысла нет в споре IaaS vs PaaS. Везде свои преимущества, главное выбирать наиболее подходящий вариант для конкретного проекта. Но в каждом из подходов надо правильно «готовить» образ, пакет и т.д.
Кстати, Дим, вопрос — а ты этот виртуальный диск в итоге попробовал? Какой реальный прирост в попугаях?
Дело в том, что в теории это все выглядит ровно также как с архивом в блобе — кем-то скачивается полностью VHD и просто монтируется. Это ничем не отличается, если узкое место — канал скачивания или запись на диск. Выигрыш может быть если этот тормозящий участок (в виде скачивания) относится к хосту, т.е. не твой виртуальный контейнер качает у себя и монтирует, а параллельно с развертыванием твоей виртуалки хост скачивает диск и монтирует на момент поднятия.
У нас была идея — делать архив с нулевой компрессией, т.е. просто контейнер. Ибо по логам и ощущениям — распаковка архива занимает больше времени чем скачивание. Проще скачать 1.5 гига flat, чем качать 500 метров но сжатых в zip и тратить время на распаковку…
А еще стоит упомянуть про волшебные 15 минут: в процедуре апгрейда OS есть очень некомфортный note
msdn.microsoft.com/en-us/library/windowsazure/hh543978.aspx
(или тут blogs.msdn.com/b/avkashchauhan/archive/2011/10/02/does-windows-azure-startup-task-have-time-limit-what-to-do-with-heavy-processing-startup-task-in-windows-azure-role.aspx)
Дело в том, что в теории это все выглядит ровно также как с архивом в блобе — кем-то скачивается полностью VHD и просто монтируется. Это ничем не отличается, если узкое место — канал скачивания или запись на диск. Выигрыш может быть если этот тормозящий участок (в виде скачивания) относится к хосту, т.е. не твой виртуальный контейнер качает у себя и монтирует, а параллельно с развертыванием твоей виртуалки хост скачивает диск и монтирует на момент поднятия.
У нас была идея — делать архив с нулевой компрессией, т.е. просто контейнер. Ибо по логам и ощущениям — распаковка архива занимает больше времени чем скачивание. Проще скачать 1.5 гига flat, чем качать 500 метров но сжатых в zip и тратить время на распаковку…
А еще стоит упомянуть про волшебные 15 минут: в процедуре апгрейда OS есть очень некомфортный note
msdn.microsoft.com/en-us/library/windowsazure/hh543978.aspx
Due to this behavior, if you have startup tasks or code in the OnStart method which takes longer than 15 minutes, you may have role instances from multiple upgrade domains offline at the same time, which may affect your service availability.
(или тут blogs.msdn.com/b/avkashchauhan/archive/2011/10/02/does-windows-azure-startup-task-have-time-limit-what-to-do-with-heavy-processing-startup-task-in-windows-azure-role.aspx)
Узкое место как раз преобразование «упакованного чего-то» в дерево папок — множественные чтения-записи приводят к очень заметному замедлению. Одно из альтернативных решений — читать архив в память и распаковывать из памяти. И распаковка из памяти, и вариант с VHD работают примерно одинаково быстро. Ускорение составляет порядка двух минут.
Да, я понимаю, что дисковая подсистема не фонтанирует там. А -2 минуты это от какого стандартного времени «как было ранее»? В принципе 2 минуты это более чем много при верхнем лимите в 15, но все же.
Общее время было порядка от трех до пяти минут, оно части варьируется из-за неравномерной нагрузки от разных виртуальных машин на железный сервер, на котором они все размещены. Пост-то не про верхний предел, пост про масштабирование при штатной работе.
Что касается верхнего предела. Перечитал SLA под более сильной лупой (интересное выделено жирным)…
Это похоже на полный произвол. Обращусь-ка я в поддержку.
Что касается верхнего предела. Перечитал SLA под более сильной лупой (интересное выделено жирным)…
In addition to the SLA Exclusions noted in Section 1.c., the SLA and any applicable Service Levels related to the Monthly Role Instance Uptime does not include any performance or availability issues to perform regular platform upgrades and patches.
Это похоже на полный произвол. Обращусь-ка я в поддержку.
Если подразумевается распаковка образа тем более 750 mb не о какой быстрой эластичности, понятно, речи быть не может.
С подключением виртуального диска хорошая идея. А есть ли мысли почему ядро FR весит 750 мегабайт? Я возможно тупой вопрос задаю. На входе картинка — алгоритм — спуск. FR написан вроде на с или с++, возможно ли занятся оптимизацией кода в сторону уменьшения дистрибутива? Я прекрасно понимаю что это все крайнесложные технические вещи которые один человек разработчик в одиночку не решит и за этим стоит целый этаж разработчиков, и поэтому глупо говорит о размере дистрибутива. Но нельзя отрицать что со временем програмные среды разработки из за конкуренции каждый раз компилируют exe все большим и большим размером. Если со стороны посмотреть. НУ не может алгоритм написанный с С или с++ занимать 750 mb. Вспомните первые версии FR. Да это он был жутко старый и там нет уже ничего от современного, но не настолько же мегобайт. Это же алгогритм какие то циклические операции с пикселями. Я про то, что в свое время писал создатель тотал коммандера. Его софт так и остается крайнешустрым и малым по размеру не зависимо от времени. Потому что он тратил адовые усилия и все писал в Delphi 2, так как понимал что новые версии компиляторов добаляют тормозов.
С подключением виртуального диска хорошая идея. А есть ли мысли почему ядро FR весит 750 мегабайт? Я возможно тупой вопрос задаю. На входе картинка — алгоритм — спуск. FR написан вроде на с или с++, возможно ли занятся оптимизацией кода в сторону уменьшения дистрибутива? Я прекрасно понимаю что это все крайнесложные технические вещи которые один человек разработчик в одиночку не решит и за этим стоит целый этаж разработчиков, и поэтому глупо говорит о размере дистрибутива. Но нельзя отрицать что со временем програмные среды разработки из за конкуренции каждый раз компилируют exe все большим и большим размером. Если со стороны посмотреть. НУ не может алгоритм написанный с С или с++ занимать 750 mb. Вспомните первые версии FR. Да это он был жутко старый и там нет уже ничего от современного, но не настолько же мегобайт. Это же алгогритм какие то циклические операции с пикселями. Я про то, что в свое время писал создатель тотал коммандера. Его софт так и остается крайнешустрым и малым по размеру не зависимо от времени. Потому что он тратил адовые усилия и все писал в Delphi 2, так как понимал что новые версии компиляторов добаляют тормозов.
Помимо исполняемого кода есть словари для словарной поддержки и описания того, как выглядят символы. Поскольку сервис умеет распознавать иероглифические языки (например, китайский), описания для этих языков тоже приходится таскать с собой. В иероглифических языках довольно много разных символов с довольно сложным начертанием, поэтому описания довольно большие, их объем и составляет значительную долю в объеме дистрибутива FRE.
Если учесть самые частые языки распознования русский и английский, сильно снизится словарь?
Просто гараздо эффективнее подготовить виртуальный жесткий диск для частых языков, чем засовывать из за англиского в дистрибутив все остальные. Поставить чекбоксы в вебинтерфейсе а потом уже грузить нужный образ.
Мне кажется без работы с дистрибутивом что то ускорить в облаке врятли больше получится.
Просто гараздо эффективнее подготовить виртуальный жесткий диск для частых языков, чем засовывать из за англиского в дистрибутив все остальные. Поставить чекбоксы в вебинтерфейсе а потом уже грузить нужный образ.
Мне кажется без работы с дистрибутивом что то ускорить в облаке врятли больше получится.
Если оставить только европейские языки, дистрибутив уменьшится в разы. Вы правы, эту проблему можно решить лучше, но всегда нужен компромисс между результатом и затратами. Кстати, скачивание и распаковка FRE была приведена только в качестве примера, а проблема с временем запуска узла — общая.
Ну если посчитать:
Часы на переработку дистрибутива под облака с выбором опций (чем точнее запрос от пользователя тем быстрее разворот)
Но как посчитать убыток? Как посчитать что пользователь ждал ждал ждал разворота диска и ушел нежождавшись… Ведь облака то у вас платные, купил — сиди уж жди. Триалка разве что даст понять по скорости. Чем быстрее работает, тем вероятность покупки подписки выше.
Часы на переработку дистрибутива под облака с выбором опций (чем точнее запрос от пользователя тем быстрее разворот)
Но как посчитать убыток? Как посчитать что пользователь ждал ждал ждал разворота диска и ушел нежождавшись… Ведь облака то у вас платные, купил — сиди уж жди. Триалка разве что даст понять по скорости. Чем быстрее работает, тем вероятность покупки подписки выше.
Будь я на AMazon EC2 у меня такой проблемы вообще не возникло. Зачем вам нужно устанавливать ваш SDK на каждом хосте.
Поднимайте не голый образ, а образ с уже всеми передустановлеными пререквизитами. Дальше Chef/Puppet/cfEngine клиент ломится за конфигурацией на главный узел и конфигурируется. На всё про всё несколько минут, большая часть из этого времени запуск ОС с образа.
Из того что я пока нагуглил про Azure, для Windows OS такой образ поднять тоже можна, но нужно явно запускать syspep, но я думаю что это всё одно более быстрый способ чем установка msi.
Поднимайте не голый образ, а образ с уже всеми передустановлеными пререквизитами. Дальше Chef/Puppet/cfEngine клиент ломится за конфигурацией на главный узел и конфигурируется. На всё про всё несколько минут, большая часть из этого времени запуск ОС с образа.
Из того что я пока нагуглил про Azure, для Windows OS такой образ поднять тоже можна, но нужно явно запускать syspep, но я думаю что это всё одно более быстрый способ чем установка msi.
Во-первых, главный узел. Как только с ним что-то случится, начинаются проблемы.
Во-вторых, что делать с изменениями кода? Их нужно как-то развертывать, не правда ли?
Вот из-за этого PaaS и удобнее. То, что вы нагуглили про образ, — это IaaS, который в Azure тоже есть и примерно такой же, как в EC2.
Во-вторых, что делать с изменениями кода? Их нужно как-то развертывать, не правда ли?
Вот из-за этого PaaS и удобнее. То, что вы нагуглили про образ, — это IaaS, который в Azure тоже есть и примерно такой же, как в EC2.
Изменения кода означают новый образ. У вас ведь не каждый день изменения выкатываются на production.
Главный узел для того puppet не проблема, клиент идёт через лоадбалансер, за ним два/три/сто инстанса puppet/cheff/whatever.
Если про вас напишет какое-то известное издание и вы получите slashdot/хабр-эфект виртуалки которім нужно будет только поднять ОС заработают быстрее чем те которые будут ещё что-то ставить.
Да кстати, как вы ставите FineReader SDK, вам достаточно xcopy или нужен полноценный инсталятор.
Так-как у вас полностью своё облако, то если переписать FineReader OCR SDK без всех регистраций/реэстра/ActiveX у вас может быть даже более простое решение держать FineReader OCR SDK на статическом read-only vhd-томе. Тогда даже запускать его можна с этого диска, главное чтобы он писал на writtable диск.
Главный узел для того puppet не проблема, клиент идёт через лоадбалансер, за ним два/три/сто инстанса puppet/cheff/whatever.
Если про вас напишет какое-то известное издание и вы получите slashdot/хабр-эфект виртуалки которім нужно будет только поднять ОС заработают быстрее чем те которые будут ещё что-то ставить.
Да кстати, как вы ставите FineReader SDK, вам достаточно xcopy или нужен полноценный инсталятор.
Так-как у вас полностью своё облако, то если переписать FineReader OCR SDK без всех регистраций/реэстра/ActiveX у вас может быть даже более простое решение держать FineReader OCR SDK на статическом read-only vhd-томе. Тогда даже запускать его можна с этого диска, главное чтобы он писал на writtable диск.
Почему не каждый день — хоть каждый час можно. В этом то и прелесть PaaS — с билда получили специальный pack, загрузили в интерфейс и сказали — развернуть. Все. А возиться вручную каждый раз с образом или даже на текущий образ заливать обновленный код — пробовали, не понравилось. Все эти puppet\chef автоматизируют именно эту рутину — обновление IaaS инстанса при изменение.
Идея PaaS уничтожает эту рутину как класс.
Идея PaaS уничтожает эту рутину как класс.
«Вот из-за этого PaaS и удобнее. То, что вы нагуглили про образ, — это IaaS, который в Azure тоже есть и примерно такой же, как в EC2. » — Что-то я не понял этого момента. Вы исспользуете Azure как раз как IaaS иначе зачем копировать ваш SDK. Задеплоили WCF/ASP.NET сервиса и Azure за вас думает сколька ему инстансов поднять надо. (Кстати у Amazon PaaS есть даже для .NET aws.amazon.com/elasticbeanstalk/).
Нет, мы используем Azure как PaaS — даем Azure пакет с основным кодом сервиса, Azure его сам разворачивает на выбранных им виртуальных машинах с обновленной операционной системой. FRE мы копируем потому, что в пакет его класть очень неудобно из-за большого размера.
Нет, Azure не думает за нас, сколько запускать экземпляров сервиса, — мы управляем этим сами.
Нет, Azure не думает за нас, сколько запускать экземпляров сервиса, — мы управляем этим сами.
ей специально ограничивают пропускную способность диска.
У них же есть provisioned iops диски
У них же есть provisioned iops диски
Sign up to leave a comment.
Облака и эластичность