Comments 10
Общие впечатления от использования Azure — громоздко и неудобно. Интерфейс сделан такое ощущение, что для роботов. Обычный юзер там разберется после бутылки, а то и не одной… Отсутствие консольного доступа к юниксовым машинами это вообще за гранью (однажды отсушил себе доступ по SSH и всё, привет). Непонятная логика расчета потребления денег — все эти "приблизительно", как-то не внушают доверия. Однажды утром увидел что машина, которая должна дойти до конца расчетного месяца с плюсом на счету просто кончилась за ночь. Уведомления о таких случаях по дефолту тоже, кстати, нет — нужно продираться сквозь дикие дебри личного кабинета, чтобы настроить простейшие оповещения.
Извините за эту экспрессию, но наболело...
Извините за эту экспрессию, но наболело...
Как вы приобретаете Azure? Напрямую через сайт, оплачивая банковской картой? Или через локального реселлера?
Я пользуюсь предложением для стартапов BizSpark. Кстати вот еще вспомил одну веселуху — перезагрузка виртуальных машин (полагаю, что скорее всего перезагружается хост) без предупреждения (!!!). Искал информацию по этому вопросу — MS говорит, мол это не баг это фича. Настраивайте HA. Это как вообще?
Это действительно "фича" облака. Облако это не совсем тоже самое, что и виртуальная инфраструктура в прежнем понимании, точнее совсем не тоже самое.
Тут предлагается использовать простоту горизонтального масштабирования вместо увеличения ресурсов одной машины. Т.е. если вам нужен стабильно работающий сервис, то вместо того, чтобы делать одну виртуалку отказоустойчивой, предлагается сделать две (можно больше, по вкусу), но попроще и объединить их в HA домен (в случае Azure — availability set). Тогда облако будет знать, что эти машинки должны находиться на разных хостах, чтобы сервис оставался доступным, независимо от того, что происходит с хостом.
Эта фича вообще характерна для всех облаков. Вместо отказоустойчивости на уровне инфрастурктуры, предлагается сделать упор на отказоустойчивость уровня приложения. Отсюда и такое количество встроенных инструментов балансировки и т.д.
Тут предлагается использовать простоту горизонтального масштабирования вместо увеличения ресурсов одной машины. Т.е. если вам нужен стабильно работающий сервис, то вместо того, чтобы делать одну виртуалку отказоустойчивой, предлагается сделать две (можно больше, по вкусу), но попроще и объединить их в HA домен (в случае Azure — availability set). Тогда облако будет знать, что эти машинки должны находиться на разных хостах, чтобы сервис оставался доступным, независимо от того, что происходит с хостом.
Эта фича вообще характерна для всех облаков. Вместо отказоустойчивости на уровне инфрастурктуры, предлагается сделать упор на отказоустойчивость уровня приложения. Отсюда и такое количество встроенных инструментов балансировки и т.д.
о availability set — написано много документации, особенно в sla https://azure.microsoft.com/en-us/support/legal/sla/virtual-machines/v1_0/ — но ни кто их лет 5 не читает(это не к претензия к вам, просто документацию читают уже после фейла).
О плановой перезагрузке- уведомления приходят по меньшей мере год. В письме указывается регионы и даты. В этом году будет еще одно улучшение.
О плановой перезагрузке- уведомления приходят по меньшей мере год. В письме указывается регионы и даты. В этом году будет еще одно улучшение.
Самая забавное, что в статье говорится про private cloud, в котором нет биллинга родного, а ругают большой Public Azure.
Согласен, что ценообразование сложное(compute minutes + storage space+ storage transactions + network bandwidth — где последние 2 параметра можно лишь приблизительно)- но альтернатива — в большую сторону округлить.
Думаю основная претензия по слову приблизительная, базируется на надписи при выборе виртуальной машины, что цена приблизительная. Там если почитать, то написано из расчета что машина работает 744ч в месяц(24*31). Но 31 день -не каждый месяц, да и машины люди выключают на ночь и выходные часто- чтобы экономить. Как это с fix price совместить- это отдельный разговор.
по поводу слишком быстрого слива денег за 1 ночь, что у вас там было то?
По доступу к консоли уже работы ведутся. https://feedback.azure.com/forums/216843-virtual-machines/suggestions/3761826-virtual-machine-console-access
Sash доступ можно и без этого восстановить правда.
Согласен, что ценообразование сложное(compute minutes + storage space+ storage transactions + network bandwidth — где последние 2 параметра можно лишь приблизительно)- но альтернатива — в большую сторону округлить.
Думаю основная претензия по слову приблизительная, базируется на надписи при выборе виртуальной машины, что цена приблизительная. Там если почитать, то написано из расчета что машина работает 744ч в месяц(24*31). Но 31 день -не каждый месяц, да и машины люди выключают на ночь и выходные часто- чтобы экономить. Как это с fix price совместить- это отдельный разговор.
по поводу слишком быстрого слива денег за 1 ночь, что у вас там было то?
По доступу к консоли уже работы ведутся. https://feedback.azure.com/forums/216843-virtual-machines/suggestions/3761826-virtual-machine-console-access
Sash доступ можно и без этого восстановить правда.
В том и задумка, что две простые виртуалки зачастую получаются дешевле одной навороченной. Т.е. если в прайсинге будет возможность создать виртуалу для которой провайдер гарантирует HA, то она будет банально дороже.
Ок, представим сценарий. У меня виртуалка с 32 ядрами, кучей ОЗУ, супер быстрыми дисками и т.д. и т.п. В итоге для того, чтобы получить не падающий по вине провайдера услуги, я, по логике MS, должен купить еще одну такую же машину и держать её постоянно включенной. Ок, по идее, можно размазать приложение по двум серверам, НО это сразу же усложнение ПО, да и многое уже готовое ПО просто нереально переписать под эту задачу (нет сорцов, дорого, etc). Вот ну никак меня не убедите, что падающая без предупреждения виртуалка — это нормальный сценарий. Это просто бред. По крайней мере нужно предлагать возможность включения live migration, пусть это и будет дороже (но это будет явно не дороже еще одной высокопроизводительной VM).
Программа BizSpark для стартапов предлагает вроде как ознакомиться с преимуществами облака от MS, но у меня лично после ознакомления есть стойкое желание держаться как можно подальше от него. На поиграться сойдет, критичные процессы — нет, спасибо.
Программа BizSpark для стартапов предлагает вроде как ознакомиться с преимуществами облака от MS, но у меня лично после ознакомления есть стойкое желание держаться как можно подальше от него. На поиграться сойдет, критичные процессы — нет, спасибо.
Вы совершенно верно поняли идею:
Я не спорю, что для ваших конкретных потребностей это может оказаться неудобно. Однако таковы реалии. Я кстати согласен, что мне бы хотелось
можно размазать приложение по двум серверам. Понятно, что дл якого-то это минус, но такова концепция облаков. Новые приложения, почти все изначально проектируются под эти механизмы.
но это будет явно не дороже еще одной высокопроизводительной VMВ том и дело, что предлагается создать две менее производительные VM. А еще лучше десяток, совсем простых. И автоматизировать их развёртывание. И добавить правило, которое будет автоматически добавлять/удалять эти VM-ки по мере увеличения/уменьшения нагрузки на приложение. Я думаю, логика понятна.
Я не спорю, что для ваших конкретных потребностей это может оказаться неудобно. Однако таковы реалии. Я кстати согласен, что мне бы хотелось
возможность включения live migrationза отдельную плату. Но у MS явно другие планы — вот что они сами говорят о HA.
Sign up to leave a comment.
Обзор возможностей Azure Stack Technical Preview 1