Комментарии 40
Один из главных плюсов Azure — устойчивость, обеспеченная несколькими одновременно работающими инстансами приложения, но любой может в любой момент упасть. Это же и недостаток — нужно переделывать архитектуру приложения.
Не уверен, но слышал, что PostgreSQL не поддерживается.
Не уверен, но слышал, что PostgreSQL не поддерживается.
таблицы предоставляют возможности NoSQL по низкой цене для приложений с простыми потребностями к доступу к данным;
Без индексов и полнотекстового поиска они мало полезны. Посмотрите как сделали Amazon и Google.
Последнее обновление для .NET чуть не убило наш сайт, долго пытались понять что это было, но отключив php (??!?!) который появился в настройках, всё заработало.
>Миф 4: В Windows Azure в качестве виртуальных машин можно использовать лишь Windows Server 2008 R2/2012.
Мне кажется, с таким названием сложно будет искоренить этот миф. Было бы, например, Microsoft Azure, может и мифа бы не появилось.
Мне кажется, с таким названием сложно будет искоренить этот миф. Было бы, например, Microsoft Azure, может и мифа бы не появилось.
У Windows Azure есть маленький географический нюанс, отличающий его от большинства облачных платформ.
Ет какой?
Сертифицированный ДЦ в Китае. И нормальный внешний канал, выторгованный MS ценой больших уступок.
Те весь трафик из китая?
Ну более или менее. Не совсем понятно что завтра будет, но пока туда подвязан лучший канал из мне известных.
А по точнее? Больший канал?
Логично предположить что в регионе китая живет 2/3 населения планеты, и что если с этим регионом начнут работать, то для реализации хотя бы GRS, CDN а именно под синхронизацию пропускная способность нужна больше. + всякие контакт-центры и прочий сапорт дешевле в Китае.
Но я лично сомневаюсь что им как-то выгодно гонять трафик из Китая для тех инстансев которые ни как не связаны с этим регионом.
Логично предположить что в регионе китая живет 2/3 населения планеты, и что если с этим регионом начнут работать, то для реализации хотя бы GRS, CDN а именно под синхронизацию пропускная способность нужна больше. + всякие контакт-центры и прочий сапорт дешевле в Китае.
Но я лично сомневаюсь что им как-то выгодно гонять трафик из Китая для тех инстансев которые ни как не связаны с этим регионом.
2/3 населения планеты? Привет из 2050 :)
Канал сносный. MS, насколько я понял из прессы сами взяли на себя цензурирование траффика. Вполне возможно, это ошметки от управляющего канала. В SLA, разумеется, ничего и никто гарантировать относитетльно подобного траффика не станет, это норма.
Сейчас залил к ним же их же SDK. Туда-сюда около 30 мбит, можешь потестировать:
chinatest.blob.core.windows.net/testcontainer2/azuresdk-v0.6.9.pkg
Вот трейс:
1. 127.0.0.1
тут неинтересно
…
8 stk-asr.comcor.ru (62.117.100.38) 37.670 ms 35.318 ms 38.212 ms
9 10gigabitethernet1-2.core1.sto1.he.net (194.68.123.187) 55.654 ms 34.256 ms 42.743 ms
10 10gigabitethernet3-2.core1.ams1.he.net (72.52.92.45) 56.225 ms 68.638 ms 57.277 ms
11 10gigabitethernet1-4.core1.lon1.he.net (72.52.92.81) 78.573 ms 84.221 ms 84.597 ms
12 10gigabitethernet7-4.core1.nyc4.he.net (72.52.92.241) 142.628 ms 146.182 ms 147.913 ms
13 10gigabitethernet5-3.core1.lax1.he.net (72.52.92.226) 205.975 ms 204.763 ms 206.092 ms
14 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) 217.130 ms 271.614 ms 307.049 ms
15 gi12-0-0.cr2.nrt1.asianetcom.net (202.147.0.125) 409.660 ms 321.634 ms 394.746 ms
16 ge-0-0-0-0.gw3.nrt4.asianetcom.net (202.147.0.226) 409.542 ms 409.632 ms 409.454 ms
17 61.8.59.22 (61.8.59.22) 409.452 ms 371.946 ms 409.744 ms
18 ge-1-0-0-0.hkg-64cbe-1b.ntwk.msn.net (207.46.41.73) 409.305 ms 433.416 ms 409.639 ms
19 ge-7-0-0-0.hkg-64cbe-1a.ntwk.msn.net (207.46.41.36) 409.604 ms
207.46.41.118 (207.46.41.118) 443.473 ms
ge-7-0-0-0.hkg-64cbe-1a.ntwk.msn.net (207.46.41.36) 368.384 ms
20 * 207.46.41.116 (207.46.41.116) 419.823 ms *
21 * * *
…
27 * * *
Входной айпишник относится к штатовскому сегменту.
Вообще в этой теме много интересного, как внутри страны доступ к ДЦ организован, как регулируются ДЦ, как распределяются каналы от их национальных провайдеров вроди алибабы и так далее.
Канал сносный. MS, насколько я понял из прессы сами взяли на себя цензурирование траффика. Вполне возможно, это ошметки от управляющего канала. В SLA, разумеется, ничего и никто гарантировать относитетльно подобного траффика не станет, это норма.
Сейчас залил к ним же их же SDK. Туда-сюда около 30 мбит, можешь потестировать:
chinatest.blob.core.windows.net/testcontainer2/azuresdk-v0.6.9.pkg
Вот трейс:
1. 127.0.0.1
тут неинтересно
…
8 stk-asr.comcor.ru (62.117.100.38) 37.670 ms 35.318 ms 38.212 ms
9 10gigabitethernet1-2.core1.sto1.he.net (194.68.123.187) 55.654 ms 34.256 ms 42.743 ms
10 10gigabitethernet3-2.core1.ams1.he.net (72.52.92.45) 56.225 ms 68.638 ms 57.277 ms
11 10gigabitethernet1-4.core1.lon1.he.net (72.52.92.81) 78.573 ms 84.221 ms 84.597 ms
12 10gigabitethernet7-4.core1.nyc4.he.net (72.52.92.241) 142.628 ms 146.182 ms 147.913 ms
13 10gigabitethernet5-3.core1.lax1.he.net (72.52.92.226) 205.975 ms 204.763 ms 206.092 ms
14 pacnet.10gigabitethernet2-3.core1.lax1.he.net (216.218.223.206) 217.130 ms 271.614 ms 307.049 ms
15 gi12-0-0.cr2.nrt1.asianetcom.net (202.147.0.125) 409.660 ms 321.634 ms 394.746 ms
16 ge-0-0-0-0.gw3.nrt4.asianetcom.net (202.147.0.226) 409.542 ms 409.632 ms 409.454 ms
17 61.8.59.22 (61.8.59.22) 409.452 ms 371.946 ms 409.744 ms
18 ge-1-0-0-0.hkg-64cbe-1b.ntwk.msn.net (207.46.41.73) 409.305 ms 433.416 ms 409.639 ms
19 ge-7-0-0-0.hkg-64cbe-1a.ntwk.msn.net (207.46.41.36) 409.604 ms
207.46.41.118 (207.46.41.118) 443.473 ms
ge-7-0-0-0.hkg-64cbe-1a.ntwk.msn.net (207.46.41.36) 368.384 ms
20 * 207.46.41.116 (207.46.41.116) 419.823 ms *
21 * * *
…
27 * * *
Входной айпишник относится к штатовскому сегменту.
Вообще в этой теме много интересного, как внутри страны доступ к ДЦ организован, как регулируются ДЦ, как распределяются каналы от их национальных провайдеров вроди алибабы и так далее.
2/3 населения планеты
Предполагаю, что регионом китая названа вся Азия :) Мда… Так азию еще никто не обзывал… Надеюсь, что Angelina_Joulie не пророк.
Ну ладно там с Китаем и Азией ;)
Вот только не могу понять, ты создал домен «чайна тест» или кто-то из MSFT?
Пытаюсь разобраться откуда в твоих иследованиях появился маршрут на Китай.
Я бы с радостью самой потестить, но больничная койка и айпад не позволят ;)
Вот только не могу понять, ты создал домен «чайна тест» или кто-то из MSFT?
Пытаюсь разобраться откуда в твоих иследованиях появился маршрут на Китай.
Я бы с радостью самой потестить, но больничная койка и айпад не позволят ;)
>Вот только не могу понять, ты создал домен «чайна тест» или кто-то из MSFT?
chinatest мой
>Пытаюсь разобраться откуда в твоих иследованиях появился маршрут на Китай.
Не понял
>Я бы с радостью самой потестить, но больничная койка и айпад не позволят ;)
Всяких онлайн трейсов, пингов, качалок и загружалок полно.
Вот тут можно, например, посмотреть актуальную ситуацию с каналом:
loadimpact.com/load-test/chinatest.blob.core.windows.net-f17e92a45b5db729238ab58d6ef14909
Для прочих красноглазых целей у меня на телефоне/планшете Promt panic.com/prompt/
chinatest мой
>Пытаюсь разобраться откуда в твоих иследованиях появился маршрут на Китай.
Не понял
>Я бы с радостью самой потестить, но больничная койка и айпад не позволят ;)
Всяких онлайн трейсов, пингов, качалок и загружалок полно.
Вот тут можно, например, посмотреть актуальную ситуацию с каналом:
loadimpact.com/load-test/chinatest.blob.core.windows.net-f17e92a45b5db729238ab58d6ef14909
Для прочих красноглазых целей у меня на телефоне/планшете Promt panic.com/prompt/
У кроме мифов есть несколько значительных минусов с которыми РЕАЛЬНО можно получить очень много проблем:
(-) файловая система в Azure имеет очень низкий IOPS — поэтому использовать что-либо кроме деплоя можно забыть
(-) Azure SQL сильно ограничен по размеру, предельному размеру транзакции, количество запросов в секунду
(-) Хотя Linux и есть в списке поддерживаемых ОС — ОДНАКО гостевых дополнений к нему нету — поэтому производительность получается на такой хорошей как можно было ожидать
… остальной список писать не буду т.к. там еще много чего есть…
(-) файловая система в Azure имеет очень низкий IOPS — поэтому использовать что-либо кроме деплоя можно забыть
(-) Azure SQL сильно ограничен по размеру, предельному размеру транзакции, количество запросов в секунду
(-) Хотя Linux и есть в списке поддерживаемых ОС — ОДНАКО гостевых дополнений к нему нету — поэтому производительность получается на такой хорошей как можно было ожидать
… остальной список писать не буду т.к. там еще много чего есть…
Думается мне что файловую систему в облаках использовать нет ни какого смысла
Перенести это все дело в NoSQL и будет вам больше IOPS
План такой:
Сздаем абстракцию AppFileStorage
И наделяем его всеми необходимыми фукнциями.
Вторым шагом пишем реализацю LocalFileSystemStorage
3. Внедряем в приложение
Все работает как и работало, классы переименовали и добавили новый.
дальше готовимся к переезду:
Пишем реализацию этой абстракции для NoSQL где ключем будет полный путь к файлу, включай диск.
Пишем тесты, если еще не написали.
Все готовы к тестированию.
Как тут любят выражаться Profit!!!
Перенести это все дело в NoSQL и будет вам больше IOPS
План такой:
Сздаем абстракцию AppFileStorage
И наделяем его всеми необходимыми фукнциями.
Вторым шагом пишем реализацю LocalFileSystemStorage
3. Внедряем в приложение
Все работает как и работало, классы переименовали и добавили новый.
дальше готовимся к переезду:
Пишем реализацию этой абстракции для NoSQL где ключем будет полный путь к файлу, включай диск.
Пишем тесты, если еще не написали.
Все готовы к тестированию.
Как тут любят выражаться Profit!!!
И вот так из хлеба можно сделать автобус :)
Если бы мне это было нужно — то Я бы просто для Windows включил RAMDISK а для Linux tmpfs с ручной репликациям данных по событию — и никаких костылей не нужно городить.
Речь шла о том что у хранилища очень невысокий IOPS и скорость доступа — если бы хотя-бы один из показателей был хорош, то претензий бы не было.
P.S. GridFS разруливает кстати — но только для небольших фрагментов ФС
Если бы мне это было нужно — то Я бы просто для Windows включил RAMDISK а для Linux tmpfs с ручной репликациям данных по событию — и никаких костылей не нужно городить.
Речь шла о том что у хранилища очень невысокий IOPS и скорость доступа — если бы хотя-бы один из показателей был хорош, то претензий бы не было.
P.S. GridFS разруливает кстати — но только для небольших фрагментов ФС
(-) Azure SQL сильно ограничен по размеру, предельному размеру транзакции, количество запросов в секунду
А подробнее, в каких сценариях вы упирались в максимальные ограничения?
открываем пул begin transaction — и если операция не закрыть — то при большом количестве транзакций, SQL сама их закроет (autocommit) — вместо того чтобы подождать.
предельный размер БД — об этом уже писали на хабре
про ограничение запросов в секунду — если начнете активно ее загружать — то увидите резкое падение IOPS
предельный размер БД — об этом уже писали на хабре
про ограничение запросов в секунду — если начнете активно ее загружать — то увидите резкое падение IOPS
я адвокатом дьявола быть не особо хочу, но все же
1. Это, судя по всему, диски с не-аппаратной реплекацией, они и не будут быстрыми. EBS или DRBD (похоже они близкие родственники) тоже не подарок. Предполагается, что I/O нагрузка будет ложится не на него. Вполне нормальное состояние сервера приложений — когда все в памяти. (кстати, нет ли случайно нормальных бенчей?)
2. Ну гдеже вы видели нормальную hosted DB, либо очень дорого, либо очень мало. Да и в целом подход к облачной инфраструктуре предполагает скорее горизонтальное масштабирование, а реляционные БД в том или ином виде будут требовать вертикального. Любая вертикалка у облачных провайдеров дорогая.
1. Это, судя по всему, диски с не-аппаратной реплекацией, они и не будут быстрыми. EBS или DRBD (похоже они близкие родственники) тоже не подарок. Предполагается, что I/O нагрузка будет ложится не на него. Вполне нормальное состояние сервера приложений — когда все в памяти. (кстати, нет ли случайно нормальных бенчей?)
2. Ну гдеже вы видели нормальную hosted DB, либо очень дорого, либо очень мало. Да и в целом подход к облачной инфраструктуре предполагает скорее горизонтальное масштабирование, а реляционные БД в том или ином виде будут требовать вертикального. Любая вертикалка у облачных провайдеров дорогая.
А как быть если используются продукты которых нет в списке поддерживаемых? Возможно ли к примеру развернуть elasticsearch?
Рекламы много, цен мало.
Сейчас использую Windows хостинг за 9$/месяц (для мелких сайтов), с возможность размещения 10 сайтов, 10 БД, 10 ГБ диска.
Можно ли такое разместить на Windows Azure и сколько это в итоге будет стоить?
Сейчас использую Windows хостинг за 9$/месяц (для мелких сайтов), с возможность размещения 10 сайтов, 10 БД, 10 ГБ диска.
Можно ли такое разместить на Windows Azure и сколько это в итоге будет стоить?
Цена «порадовала». Специально использовал платный аккаунт на азуре.
Везде значилось — «плата за потребление»
Создал один сайт, загрузил туда заглушку на mvc4, нигде ничего не прописывал для индексации поисковиками, заходил на созданный сайт раз 5 и в конце месяца получил счет в 500 руб.
Везде значилось — «плата за потребление»
Создал один сайт, загрузил туда заглушку на mvc4, нигде ничего не прописывал для индексации поисковиками, заходил на созданный сайт раз 5 и в конце месяца получил счет в 500 руб.
Главный миф — что Azure это облачные технологии, вот Office360, Facebook, Akamai, Gmail, last.fm, Dropbox, Weebly — это облачные приложения, а Azure это способ развернуть в облачке не облачные приложения, запихнув их в виртуальную машину, а действительно облачное приложение работает без виртуальной машины, на самих ресурсах облака.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 заблуждений о Windows Azure и Open Source