Comments 40
Один из главных плюсов Azure — устойчивость, обеспеченная несколькими одновременно работающими инстансами приложения, но любой может в любой момент упасть. Это же и недостаток — нужно переделывать архитектуру приложения.
Не уверен, но слышал, что PostgreSQL не поддерживается.
Не уверен, но слышал, что PostgreSQL не поддерживается.
0
таблицы предоставляют возможности NoSQL по низкой цене для приложений с простыми потребностями к доступу к данным;
Без индексов и полнотекстового поиска они мало полезны. Посмотрите как сделали Amazon и Google.
+5
Последнее обновление для .NET чуть не убило наш сайт, долго пытались понять что это было, но отключив php (??!?!) который появился в настройках, всё заработало.
+6
>Миф 4: В Windows Azure в качестве виртуальных машин можно использовать лишь Windows Server 2008 R2/2012.
Мне кажется, с таким названием сложно будет искоренить этот миф. Было бы, например, Microsoft Azure, может и мифа бы не появилось.
Мне кажется, с таким названием сложно будет искоренить этот миф. Было бы, например, Microsoft Azure, может и мифа бы не появилось.
+9
У Windows Azure есть маленький географический нюанс, отличающий его от большинства облачных платформ.
0
Ет какой?
0
Сертифицированный ДЦ в Китае. И нормальный внешний канал, выторгованный MS ценой больших уступок.
0
Те весь трафик из китая?
0
Ну более или менее. Не совсем понятно что завтра будет, но пока туда подвязан лучший канал из мне известных.
0
А по точнее? Больший канал?
Логично предположить что в регионе китая живет 2/3 населения планеты, и что если с этим регионом начнут работать, то для реализации хотя бы GRS, CDN а именно под синхронизацию пропускная способность нужна больше. + всякие контакт-центры и прочий сапорт дешевле в Китае.
Но я лично сомневаюсь что им как-то выгодно гонять трафик из Китая для тех инстансев которые ни как не связаны с этим регионом.
Логично предположить что в регионе китая живет 2/3 населения планеты, и что если с этим регионом начнут работать, то для реализации хотя бы GRS, CDN а именно под синхронизацию пропускная способность нужна больше. + всякие контакт-центры и прочий сапорт дешевле в Китае.
Но я лично сомневаюсь что им как-то выгодно гонять трафик из Китая для тех инстансев которые ни как не связаны с этим регионом.
-1
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 * * *
Входной айпишник относится к штатовскому сегменту.
Вообще в этой теме много интересного, как внутри страны доступ к ДЦ организован, как регулируются ДЦ, как распределяются каналы от их национальных провайдеров вроди алибабы и так далее.
0
2/3 населения планеты
Предполагаю, что регионом китая названа вся Азия :) Мда… Так азию еще никто не обзывал… Надеюсь, что Angelina_Joulie не пророк.
0
Ну ладно там с Китаем и Азией ;)
Вот только не могу понять, ты создал домен «чайна тест» или кто-то из MSFT?
Пытаюсь разобраться откуда в твоих иследованиях появился маршрут на Китай.
Я бы с радостью самой потестить, но больничная койка и айпад не позволят ;)
Вот только не могу понять, ты создал домен «чайна тест» или кто-то из MSFT?
Пытаюсь разобраться откуда в твоих иследованиях появился маршрут на Китай.
Я бы с радостью самой потестить, но больничная койка и айпад не позволят ;)
0
>Вот только не могу понять, ты создал домен «чайна тест» или кто-то из 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/
0
У кроме мифов есть несколько значительных минусов с которыми РЕАЛЬНО можно получить очень много проблем:
(-) файловая система в Azure имеет очень низкий IOPS — поэтому использовать что-либо кроме деплоя можно забыть
(-) Azure SQL сильно ограничен по размеру, предельному размеру транзакции, количество запросов в секунду
(-) Хотя Linux и есть в списке поддерживаемых ОС — ОДНАКО гостевых дополнений к нему нету — поэтому производительность получается на такой хорошей как можно было ожидать
… остальной список писать не буду т.к. там еще много чего есть…
(-) файловая система в Azure имеет очень низкий IOPS — поэтому использовать что-либо кроме деплоя можно забыть
(-) Azure SQL сильно ограничен по размеру, предельному размеру транзакции, количество запросов в секунду
(-) Хотя Linux и есть в списке поддерживаемых ОС — ОДНАКО гостевых дополнений к нему нету — поэтому производительность получается на такой хорошей как можно было ожидать
… остальной список писать не буду т.к. там еще много чего есть…
+4
Думается мне что файловую систему в облаках использовать нет ни какого смысла
Перенести это все дело в NoSQL и будет вам больше IOPS
План такой:
Сздаем абстракцию AppFileStorage
И наделяем его всеми необходимыми фукнциями.
Вторым шагом пишем реализацю LocalFileSystemStorage
3. Внедряем в приложение
Все работает как и работало, классы переименовали и добавили новый.
дальше готовимся к переезду:
Пишем реализацию этой абстракции для NoSQL где ключем будет полный путь к файлу, включай диск.
Пишем тесты, если еще не написали.
Все готовы к тестированию.
Как тут любят выражаться Profit!!!
Перенести это все дело в NoSQL и будет вам больше IOPS
План такой:
Сздаем абстракцию AppFileStorage
И наделяем его всеми необходимыми фукнциями.
Вторым шагом пишем реализацю LocalFileSystemStorage
3. Внедряем в приложение
Все работает как и работало, классы переименовали и добавили новый.
дальше готовимся к переезду:
Пишем реализацию этой абстракции для NoSQL где ключем будет полный путь к файлу, включай диск.
Пишем тесты, если еще не написали.
Все готовы к тестированию.
Как тут любят выражаться Profit!!!
+1
И вот так из хлеба можно сделать автобус :)
Если бы мне это было нужно — то Я бы просто для Windows включил RAMDISK а для Linux tmpfs с ручной репликациям данных по событию — и никаких костылей не нужно городить.
Речь шла о том что у хранилища очень невысокий IOPS и скорость доступа — если бы хотя-бы один из показателей был хорош, то претензий бы не было.
P.S. GridFS разруливает кстати — но только для небольших фрагментов ФС
Если бы мне это было нужно — то Я бы просто для Windows включил RAMDISK а для Linux tmpfs с ручной репликациям данных по событию — и никаких костылей не нужно городить.
Речь шла о том что у хранилища очень невысокий IOPS и скорость доступа — если бы хотя-бы один из показателей был хорош, то претензий бы не было.
P.S. GridFS разруливает кстати — но только для небольших фрагментов ФС
0
(-) Azure SQL сильно ограничен по размеру, предельному размеру транзакции, количество запросов в секунду
А подробнее, в каких сценариях вы упирались в максимальные ограничения?
0
открываем пул begin transaction — и если операция не закрыть — то при большом количестве транзакций, SQL сама их закроет (autocommit) — вместо того чтобы подождать.
предельный размер БД — об этом уже писали на хабре
про ограничение запросов в секунду — если начнете активно ее загружать — то увидите резкое падение IOPS
предельный размер БД — об этом уже писали на хабре
про ограничение запросов в секунду — если начнете активно ее загружать — то увидите резкое падение IOPS
0
я адвокатом дьявола быть не особо хочу, но все же
1. Это, судя по всему, диски с не-аппаратной реплекацией, они и не будут быстрыми. EBS или DRBD (похоже они близкие родственники) тоже не подарок. Предполагается, что I/O нагрузка будет ложится не на него. Вполне нормальное состояние сервера приложений — когда все в памяти. (кстати, нет ли случайно нормальных бенчей?)
2. Ну гдеже вы видели нормальную hosted DB, либо очень дорого, либо очень мало. Да и в целом подход к облачной инфраструктуре предполагает скорее горизонтальное масштабирование, а реляционные БД в том или ином виде будут требовать вертикального. Любая вертикалка у облачных провайдеров дорогая.
1. Это, судя по всему, диски с не-аппаратной реплекацией, они и не будут быстрыми. EBS или DRBD (похоже они близкие родственники) тоже не подарок. Предполагается, что I/O нагрузка будет ложится не на него. Вполне нормальное состояние сервера приложений — когда все в памяти. (кстати, нет ли случайно нормальных бенчей?)
2. Ну гдеже вы видели нормальную hosted DB, либо очень дорого, либо очень мало. Да и в целом подход к облачной инфраструктуре предполагает скорее горизонтальное масштабирование, а реляционные БД в том или ином виде будут требовать вертикального. Любая вертикалка у облачных провайдеров дорогая.
0
А как быть если используются продукты которых нет в списке поддерживаемых? Возможно ли к примеру развернуть elasticsearch?
0
Рекламы много, цен мало.
Сейчас использую Windows хостинг за 9$/месяц (для мелких сайтов), с возможность размещения 10 сайтов, 10 БД, 10 ГБ диска.
Можно ли такое разместить на Windows Azure и сколько это в итоге будет стоить?
Сейчас использую Windows хостинг за 9$/месяц (для мелких сайтов), с возможность размещения 10 сайтов, 10 БД, 10 ГБ диска.
Можно ли такое разместить на Windows Azure и сколько это в итоге будет стоить?
0
Цена «порадовала». Специально использовал платный аккаунт на азуре.
Везде значилось — «плата за потребление»
Создал один сайт, загрузил туда заглушку на mvc4, нигде ничего не прописывал для индексации поисковиками, заходил на созданный сайт раз 5 и в конце месяца получил счет в 500 руб.
Везде значилось — «плата за потребление»
Создал один сайт, загрузил туда заглушку на mvc4, нигде ничего не прописывал для индексации поисковиками, заходил на созданный сайт раз 5 и в конце месяца получил счет в 500 руб.
0
Главный миф — что Azure это облачные технологии, вот Office360, Facebook, Akamai, Gmail, last.fm, Dropbox, Weebly — это облачные приложения, а Azure это способ развернуть в облачке не облачные приложения, запихнув их в виртуальную машину, а действительно облачное приложение работает без виртуальной машины, на самих ресурсах облака.
0
Sign up to leave a comment.
10 заблуждений о Windows Azure и Open Source