Comments 49
А как-же Linode и DO?
Во-первых статья и так стала очень большой, из-за чего пришлось часть результатов IOzone оставить просто в xls файле (хотя они и вполне хорошие). Можно протестировать самостоятельно, мы бесплатный триал дадим для тестов в InfoboxCloud – напишите только как указано в конце статьи. Во-вторых позиционирование у Linode и DO все-таки отличается: у них основная ЦА — классический хостинг и разработчики, а мы занимаемся и Enterprise клиентами.
Если будете тестировать добавьте еще RunAbove.
Зарегистрировавшись по реф.ссылке и привязав карту или paypal(проверку на платежеспособность не делает) получите 10 баксов на тест, можете и по другой, главное реферальной.
Выходите с аккаунта.
Переходите по ссылке, авторизируетесь, это разблокирует IBM Power8 для мощных конфигураций, в ноябре за это еще давали 32 бакса, но уже вроде как нет.
Выходите с аккаунта и переходите по ссылке , это разблокирует «sandbox» тарифы за 2.5 и 5 баксов, и получите 5 баксов на счет.
Запускаете инстанс и тестируете)
Максимальная конфигурация имеет 176 потоков.
Зарегистрировавшись по реф.ссылке и привязав карту или paypal(проверку на платежеспособность не делает) получите 10 баксов на тест, можете и по другой, главное реферальной.
Выходите с аккаунта.
Переходите по ссылке, авторизируетесь, это разблокирует IBM Power8 для мощных конфигураций, в ноябре за это еще давали 32 бакса, но уже вроде как нет.
Выходите с аккаунта и переходите по ссылке , это разблокирует «sandbox» тарифы за 2.5 и 5 баксов, и получите 5 баксов на счет.
Запускаете инстанс и тестируете)
Максимальная конфигурация имеет 176 потоков.
Ах да, для увеличения квот пишите в сюда
В калькуляторе ресурсов что-то максимальная машина слабовата.
64ГБ озу и 840ГБ дисковой по нынешним временам не слишком то много.
1 виртуальный процессор чему равен?
64ГБ озу и 840ГБ дисковой по нынешним временам не слишком то много.
1 виртуальный процессор чему равен?
В панели управления облаком калькулятор другой. При создании сервера вы сразу видите примерную стоимость и таких лимитов как на сайте нет. Особых ограничений по ресурсам нет, если в панели чего-то не хватит — напишите и сделаем больше (кроме частоты CPU, ее максимальное значение 2.3 ггц). На сайте сделаем релевантнее, спасибо за замечание. Если вам нужно посчитать всю инфраструктуру сейчас — можете воспользоваться прототипом калькулятора инфраструктуры calculator.sandbox.infoboxcloud.ru.
1 ядро с заданной частотой преобазуется в процессорное время cpu хоста, которое позволяет получить производительность примерно равную производительности одного ядра такого же физического сервера с таким cpu.
1 ядро с заданной частотой преобазуется в процессорное время cpu хоста, которое позволяет получить производительность примерно равную производительности одного ядра такого же физического сервера с таким cpu.
Посчитал один сервер. Получил стоимость полёта на луну.
Сервер: stat; Ядра: 12; Частота: 2000; Память: 160; Диск: 2000; IP: 1; Стоимость: 6541290.00;
Сервер: stat; Ядра: 12; Частота: 2000; Память: 160; Диск: 2000; IP: 1; Стоимость: 6541290.00;
При подсчете вы указали космический процессор с двумя тысячами гигагерц, не удивляйтесь. В калькуляторе на сайте лимиты будут.
Правильно так:
Сервер: habr; Ядра: 12; Частота: 2; Память: 160; Диск: 2000; IP:; Стоимость: 67680.00;
Правильно так:
Сервер: habr; Ядра: 12; Частота: 2; Память: 160; Диск: 2000; IP:; Стоимость: 67680.00;
Да, был невнимателен, и не прочитал что там ггц.
Но 67680р это 812160р в год
2. Сервер в облаке Amazon AWS
Аналогичная по мощности конфигурация называется i2.4xlarge
Разовый годовой платёж $7280 и $0.991 за час
Итого стоимость за год 7280+0.991*24*365=$15961,16
Разница стоимости идёт на проценты, а не в разы.
Но 67680р это 812160р в год
2. Сервер в облаке Amazon AWS
Аналогичная по мощности конфигурация называется i2.4xlarge
Разовый годовой платёж $7280 и $0.991 за час
Итого стоимость за год 7280+0.991*24*365=$15961,16
Разница стоимости идёт на проценты, а не в разы.
А вы посчитайте еще и стоимость трафика. Все скрытые расходы важно учитывать заранее, ведь за них потом придется заплатить.
Трафик примерно
До 10 ТБ / месяц $0.090 за ГБ (Итого 900$ за 10ТБ)
До 10 ТБ / месяц $0.090 за ГБ (Итого 900$ за 10ТБ)
900*53=47700 рублей в месяц в Amazon только за трафик.
У нас: 3 терабайта трафика бесплатно, 6000*0.5 = 3000 рублей в месяц за трафик.
Разница очевидна :)
У нас: 3 терабайта трафика бесплатно, 6000*0.5 = 3000 рублей в месяц за трафик.
Разница очевидна :)
Не очень понял откуда вылезло 90* 53.
В исходном расчёте было 5000 гигабайт исходящего трафика в месяц.
Что будет стоить 450$ в месяц.
В исходном расчёте было 5000 гигабайт исходящего трафика в месяц.
Что будет стоить 450$ в месяц.
900*53 появилось из вашего комментария «До 10 ТБ / месяц $0.090 за ГБ (Итого 900$ за 10ТБ)»
Если нужно 5000 гб, то у Amazon это 450*53 = 23850 рублей. в месяц
У нас 5000 — 3000 (бесплатно) = 2000*0.5 = 1000 рублей в месяц. Разница в 23 раза в нашу пользу.
Если нужно 5000 гб, то у Amazon это 450*53 = 23850 рублей. в месяц
У нас 5000 — 3000 (бесплатно) = 2000*0.5 = 1000 рублей в месяц. Разница в 23 раза в нашу пользу.
Это пока классическое сравнивание сферического коня в вакуме. Сервер который требует SSD обычно является сервером БД. И трафик генерирует минимальный.
Но для сравнения аренда канала в Москве с гарантированной полосой в 1Гбмт стоит примерно 20т.р. в Месяц.
При обычной загрузке волной с пиками в районе 18 часов позволяет в месяц отдать 150ТБ.
Ваша стоимость за 150ТБ будет в районе 73.5 т. р. в месяц.
Но для сравнения аренда канала в Москве с гарантированной полосой в 1Гбмт стоит примерно 20т.р. в Месяц.
При обычной загрузке волной с пиками в районе 18 часов позволяет в месяц отдать 150ТБ.
Ваша стоимость за 150ТБ будет в районе 73.5 т. р. в месяц.
>Но для сравнения аренда канала в Москве с гарантированной полосой в 1Гбмт стоит примерно 20т.р. в Месяц.
Мы сравнивали с Amazon. А теперь вы сравниваете с арендой канала для дедика где-то.
Наши аплинки в Москве в лучшем ДЦ, подключенном к MSK IX.
Всегда найти можно дешевле, в том числе собрать на коленке. Мы не являемся дискаунтерами, мы предлагаем сервис корпоративного уровня по доступным ценам,
Мы сравнивали с Amazon. А теперь вы сравниваете с арендой канала для дедика где-то.
Наши аплинки в Москве в лучшем ДЦ, подключенном к MSK IX.
Всегда найти можно дешевле, в том числе собрать на коленке. Мы не являемся дискаунтерами, мы предлагаем сервис корпоративного уровня по доступным ценам,
Не где-то а в ДЦ наколенного типа, а в Tier III Design. В недалёком будущем который станет и Tier III Operational.
Tier III Design – это сертификация документации дата-центра :) Facility уже относится к самому дата-центру. Таким образом статус Tier III Design говорит только о том, что документация у ДЦ хорошая.
Естественное сравнение облака и реального железа. Крупные проекты не идут в облака именно по причине стоимости.
Еще как идут. Честно говоря основная проблема в облаке — не найти новых клиентов, а успевать расти так быстро, чтобы всем хватило ресурсов. Справляемся.
Вот тут можно почитать о динамике InfoboxCloud. Бизнес уже во всю доверяет облакам infoboxcloud.ru/community/blog/corpnews/211.html
Треть из 15 000 серверов создано за последние 2 месяца!
Вот тут можно почитать о динамике InfoboxCloud. Бизнес уже во всю доверяет облакам infoboxcloud.ru/community/blog/corpnews/211.html
Треть из 15 000 серверов создано за последние 2 месяца!
>Сервер который требует SSD обычно является сервером БД
Любой сервер в InfoboxCloud (Москва, Амстердам) получает Enterprise–SSD кеш. Даже маленький дешевый сервер с 2 гб памяти. Таким образом его преимуществами пользуются все клиенты InfoboxCloud.
Любой сервер в InfoboxCloud (Москва, Амстердам) получает Enterprise–SSD кеш. Даже маленький дешевый сервер с 2 гб памяти. Таким образом его преимуществами пользуются все клиенты InfoboxCloud.
Так же добавлю что если не гнаться за облаками и купить железный сервер то его стоимость по текущему курсу доллара будет в районе 600т.р. Т.е. сервер окупится примерно за 9 месяцев. Если включить в стоимость сервера сервис контракт и зип то окупаемость станет 1 год примерно.
>если не гнаться за облаками и купить железный сервер
Его нужно будет обслуживать, он является точкой отказа.
В облаке вас не волнует, что у сервера начала глючить памяти или развалился raid. У вас нет амортизационной стоимости, вам не надо обслуживать железо. Если ломается физический хост облака — для вас ничего не меняется, это не отражается ни на чеке, ни на доступности. К тому же вам не нужно делать капитальные расходы сразу, а просто платить абонентскую плату. Оставшиеся деньги можно пустить в оборот компании и получить больше. Для экономии можно использовать автомасштабирование или изменять вручную параметры облачного сервера и не переплачивать за неиспользуемые в данный момент времени ресурсы. Если ваш бизнес растет — увеличивать доступные ресурсы также просто, не нужно покупать еще сервер.
Его нужно будет обслуживать, он является точкой отказа.
В облаке вас не волнует, что у сервера начала глючить памяти или развалился raid. У вас нет амортизационной стоимости, вам не надо обслуживать железо. Если ломается физический хост облака — для вас ничего не меняется, это не отражается ни на чеке, ни на доступности. К тому же вам не нужно делать капитальные расходы сразу, а просто платить абонентскую плату. Оставшиеся деньги можно пустить в оборот компании и получить больше. Для экономии можно использовать автомасштабирование или изменять вручную параметры облачного сервера и не переплачивать за неиспользуемые в данный момент времени ресурсы. Если ваш бизнес растет — увеличивать доступные ресурсы также просто, не нужно покупать еще сервер.
Для нас это выгодно просто потому, что наши кластеры имеют гораздо более высокую загрузку, чем это возможно у клиента. Мы эффективнее используем железо, оно никогда не простаивает. Вы же в облаке можете просто потреблять тот обьем ресурсов, который необходим.
Ещё как волнует. Падают Цоды целиком, магистральные каналы. Мало было аварий когда амазон был недоступен?
Именно поэтому мы используем один из 5и в мире ЦОДов, соответствующих уровням надежности Tier III Design, Tier III Facility и Tier III Operational. В России такой ДЦ единственный, три в США, один в Великобритании.
infoboxcloud.ru/community/blog/148.html
В случае падения магистрального канала проблем это не вызовет. Аплинков у нас много в каждом ДЦ.
infoboxcloud.ru/community/blog/148.html
В случае падения магистрального канала проблем это не вызовет. Аплинков у нас много в каждом ДЦ.
Я, честно, немного растерян от таких показателей скорости работы SSD в облаках. Конечно, надежность облака — это штука важная…
Но, однажды мне пришлось сдавать под ключ сервер у hetzner (дешевый на «59 евро» в 2013), так вот, я там тоже запустил на системе заказчика CrystakDisk тест, и скорость 2х SSD хардов была что-то в районе 760 Мб в секунду (virtualbox + windows, сам сервер debian, настроил-передал-забыл).
Я ей богу не понимаю, зачем покупать облачный сервер с отличным iops, но совершенно никакой скоростью за 133 евро «новыми» (или 200! евро «старыми»), если упомянутую выше надежность можно реализовать через резервное копирование данных на «маленькое и дешевое облако», S3 или Glacier (по убыванию «быстрее выдернуть/стоимость»). При этом сэкономить на продуктах и получить выигрыш в производительности.
Но, однажды мне пришлось сдавать под ключ сервер у hetzner (дешевый на «59 евро» в 2013), так вот, я там тоже запустил на системе заказчика CrystakDisk тест, и скорость 2х SSD хардов была что-то в районе 760 Мб в секунду (virtualbox + windows, сам сервер debian, настроил-передал-забыл).
Я ей богу не понимаю, зачем покупать облачный сервер с отличным iops, но совершенно никакой скоростью за 133 евро «новыми» (или 200! евро «старыми»), если упомянутую выше надежность можно реализовать через резервное копирование данных на «маленькое и дешевое облако», S3 или Glacier (по убыванию «быстрее выдернуть/стоимость»). При этом сэкономить на продуктах и получить выигрыш в производительности.
Облачный сервер лучше выделенного тем, что для всех виртуальных машин выполняется репликация на несколько хостов. В случае падения любого сервер будет доступен и все данные сохранятся, восстановление делать будет не нужно. Кроме этого в облачном сервере в любое время вы можете добавить или убрать ресурсов у сервера или использовать автомасштабирование. Высокую производительность получить не сложно, этим ежедневно занимаются геймеры на десктопах, однако такой вариант, не подходит для надежной работы сервера клиента. В случае, когда вы сами организуете резервное копирование и восстановление, во-первых вы платите своим временем в каждый инцидент, а во-вторых в случае падения хоста возникнет существенный простой.
По тестам линейного копирования dd в InfoboxCloud получаются значения 600-1gb/сек (конечно с sync, чтобы эксперимент был честный), результаты бенчмарков зависят от их настроек. В нашем случае для всех тестируемых использовались одни и те же настройки.
По тестам линейного копирования dd в InfoboxCloud получаются значения 600-1gb/сек (конечно с sync, чтобы эксперимент был честный), результаты бенчмарков зависят от их настроек. В нашем случае для всех тестируемых использовались одни и те же настройки.
Облачный сервер лучше выделенного тем, что для всех виртуальных машин выполняется репликация на несколько хостов. В случае падения любого сервер будет доступен и все данные сохранятся, восстановление делать будет не нужно.
Только все почему-то считают что если сервер упал, то он и правда упал, хрясь и… ничего не осталось. А на деле такие маленькие сервера (на примере предложений в ЕС) падают только по невнимательности того, кто сервер контролирует.
Пропустил ошибки на диске — диск умер (после нескольких лет), из-за этого рейд тупит и все лагает. Или место кончилось под логи, и из-за этого не пускает по SSH так как не может записать лог.
БП — еще никогда не умирал на моей памяти, планки не начинали внезапно глючить. Всегда были проблемы с HDD.
В случае, когда вы сами организуете резервное копирование и восстановление, во-первых вы платите своим временем в каждый инцидент, а во-вторых в случае падения хоста возникнет существенный простой.
Если пользователю сервер положили удаленно — тут и облачный так же положат, софт же на репликах один и тот же, как и уязвимости.
Я вот не могу придумать более причин падения кроме как из-за дисковой системы или кривой планировки софта (или самого софта), когда ОЗУ кончается и свап. Канал и ддос — у любого ДЦ есть как базовая защита, так и платная + есть провайдеры вроде CloudFlare.
Про канал: ведь если вашего клиента будут DDoS'ить, ваша автоматика по достижению лимита «наелись траффиком — хватит!» отключит проблемного клиента, у которого один из самых дешевых тарифов?
>Я вот не могу придумать более причин падения кроме как из-за дисковой системы
Raid внезапно умер например у выделенного сервера и прощай данные. В нашем облаке такого не случится из-за репликации всех VM.
Таких примеров бесчисленное множество и тут вопрос: готовы ли вы рисковать и использовать выделенный сервер — точку отказа со всеми рисками.
Про канал: свыше 3 терабайт на подписку канал становится платным 0.5 коп. за гигабайт исходящего трафика, входящий бесплатен. Тариф един для InfoboxCloud. Мы защищаемся от DDoS самыми разнообразными способами. Блокировка ip клиента до завершения DDoS – самая крайняя мера.
Raid внезапно умер например у выделенного сервера и прощай данные. В нашем облаке такого не случится из-за репликации всех VM.
Таких примеров бесчисленное множество и тут вопрос: готовы ли вы рисковать и использовать выделенный сервер — точку отказа со всеми рисками.
Про канал: свыше 3 терабайт на подписку канал становится платным 0.5 коп. за гигабайт исходящего трафика, входящий бесплатен. Тариф един для InfoboxCloud. Мы защищаемся от DDoS самыми разнообразными способами. Блокировка ip клиента до завершения DDoS – самая крайняя мера.
Raid внезапно умер например у выделенного сервера и прощай данные. В нашем облаке такого не случится из-за репликации всех VM.
Таких примеров бесчисленное множество и тут вопрос: готовы ли вы рисковать и использовать выделенный сервер — точку отказа со всеми рисками.
Я согласен с тем, что у вас не может внезапный вылет рейда сильно сказаться на работе системы, но не согласен с вашими аргументами в Облако Vs. «железный» сервер в плане риска.
Если на выделенном сервере настроен бекап (как полный, так и инкрементный), то величина потерь при вылете моего рейда или чего-нибудь у вас будет меньше у того, кто чаще делает бекап.
В этом случае облако лишь уменьшает время на восстановление. В моем случае это 2й сервер или, за неимением, ремонт в ДЦ сотрудниками этого ДЦ (замена контроллера или дисков), в вашем случае это несколько кликов мыши или автоматика уже сама это сделает.
И чтобы не было таких рисков (кроме как «внезапно!1»), администратор должен «осматривать» свой сервер и проверять «все ли ок».
Выше вы написали, что спрос велик, и уже более 15000 облачных серверов создано клиентами.
Объем продаж — это не показатель качества продукта, а просто цифры успеха фирмы.
Облака сейчас: 1) на слуху, 2) «поставил и забыл»; и по сути как минимум эти 2 пункта «рисуют» число в 15к серверов.
Пара нюансов про «скорость SSD в облаках»:
1. В AWS они тестировали EBS on SSD. Т.е. сетевое хранилище, которое ограничено 24 iops (3000 burst mode на 30 минут). В качестве root на всех машинах в EC2 всегда используется EBS. Это единственное постоянное хранилище. Потому там и получили магические 3000 iops на скриншотах.
Локальные же SSD-диски, которые на M3 указаны в качестве SSD Storage, надо монтировать отдельно при создании — они доступны как Instance sotage и да — они эфемерны. Т.е. обнуляются при рестарте инстанса. В этом они полностью идентичны Temp-дискам в Azure.
2. В Azure точно также диск C всегда является сетевым. Локальный SSD-диск, доступный на некоторых типах инстансов, только D и он тоже эфемерен, о чём и гласит текстовый документ, про который вы так громко заявили "что использование SSD диска в Azure – на свой страх и риск" и "Azure предупреждает о том, что использование SSD диска небезопасно и не рекомендуется для постоянного хранения данных". Божтымой. Читайте описание сервиса. Этот текстовый документ всего-лишь напоминает тем, кто не читает описание сервиса, что D: — это Temporary drive, что он обнуляется при рестартах.
3. Для расчёта цены взят регион «Ирландия».
… как самый дорогой в AWS, ага. Был бы новый Франкфурт дороже — сравнивали бы с ним, оно понятно. А вот если с Орегоном посравнивать.
Да ещё и не с On demand, а с Reserved, например.
Я, конечно, понимаю, что пиар подразумевает истеричность и вбросы на вентилятор… Но здесь я даже затрудняюсь понять — это наивная безграмотность или подтасовка такая нелепая?
А по поводу «зачем платить» — здесь больше играет скорость разворачивания. В AWS/Azure вы один раз настраиваете машину и в любой момент за пару минут поднимаете хоть с десяток _идентичных_ машин. Со всеми точно такими же настройками (потому что системный диск сетевой и персистентный — так что его можно в любой момент клонировать. А все эти SSD/Temporary диски — они под локальные данные.
Или же просто имеющуюся машину переключаете на другой тип инстанса — быстро добавляя ей ядер/памяти.
Т.е., допустим, настроив один раз ту же cassandra так, чтоб хранила данные на локальном (эфемерном) диске, можно в любой момент поднять ещё десяток машин — они сами войдут в кластер, сами всосут в себя данные на быстрые диски и вы сразу получите нужный прирост. Потом просто по-одной выводите машины и они сами свои данные сливают на остальных.
И всё это можно делать скриптами через AWS/Azure API без ручной работы.
А теперь представьте себе, что призойдёт, если по случае праздника/акции/положения звёзд ваш сервер в hetzner не справляется с нагрузкой и надо БЫСТРО развернуть второй такойже и ещё и балансировщик сверху поставить…
1. В AWS они тестировали EBS on SSD. Т.е. сетевое хранилище, которое ограничено 24 iops (3000 burst mode на 30 минут). В качестве root на всех машинах в EC2 всегда используется EBS. Это единственное постоянное хранилище. Потому там и получили магические 3000 iops на скриншотах.
Локальные же SSD-диски, которые на M3 указаны в качестве SSD Storage, надо монтировать отдельно при создании — они доступны как Instance sotage и да — они эфемерны. Т.е. обнуляются при рестарте инстанса. В этом они полностью идентичны Temp-дискам в Azure.
2. В Azure точно также диск C всегда является сетевым. Локальный SSD-диск, доступный на некоторых типах инстансов, только D и он тоже эфемерен, о чём и гласит текстовый документ, про который вы так громко заявили "что использование SSD диска в Azure – на свой страх и риск" и "Azure предупреждает о том, что использование SSD диска небезопасно и не рекомендуется для постоянного хранения данных". Божтымой. Читайте описание сервиса. Этот текстовый документ всего-лишь напоминает тем, кто не читает описание сервиса, что D: — это Temporary drive, что он обнуляется при рестартах.
3. Для расчёта цены взят регион «Ирландия».
… как самый дорогой в AWS, ага. Был бы новый Франкфурт дороже — сравнивали бы с ним, оно понятно. А вот если с Орегоном посравнивать.
Да ещё и не с On demand, а с Reserved, например.
Я, конечно, понимаю, что пиар подразумевает истеричность и вбросы на вентилятор… Но здесь я даже затрудняюсь понять — это наивная безграмотность или подтасовка такая нелепая?
А по поводу «зачем платить» — здесь больше играет скорость разворачивания. В AWS/Azure вы один раз настраиваете машину и в любой момент за пару минут поднимаете хоть с десяток _идентичных_ машин. Со всеми точно такими же настройками (потому что системный диск сетевой и персистентный — так что его можно в любой момент клонировать. А все эти SSD/Temporary диски — они под локальные данные.
Или же просто имеющуюся машину переключаете на другой тип инстанса — быстро добавляя ей ядер/памяти.
Т.е., допустим, настроив один раз ту же cassandra так, чтоб хранила данные на локальном (эфемерном) диске, можно в любой момент поднять ещё десяток машин — они сами войдут в кластер, сами всосут в себя данные на быстрые диски и вы сразу получите нужный прирост. Потом просто по-одной выводите машины и они сами свои данные сливают на остальных.
И всё это можно делать скриптами через AWS/Azure API без ручной работы.
А теперь представьте себе, что призойдёт, если по случае праздника/акции/положения звёзд ваш сервер в hetzner не справляется с нагрузкой и надо БЫСТРО развернуть второй такойже и ещё и балансировщик сверху поставить…
>Локальные же SSD-диски, которые на M3 указаны в качестве SSD Storage, надо монтировать отдельно при создании — они доступны как Instance sotage и да — они эфемерны. Т.е. обнуляются при рестарте инстанса
A какой смысл в их тестировании? При каждой перезагрузке данные с них пропадают. В InfoboxCloud все дисковое пространство покрывается SSD–кешем и не только не обнуляется, но и реплицируется, обеспечивая надежность хранения данных. Облачные сервера нужны не только для того, чтобы их тестировать, но и чтобы работать с ними. Сервер, на котором уничтожаются данные на каждой перезагрузке не подходит для хранения данных. Сравнивать нужно сравнимое. Никто не мешает в InfoboxCloud подключить ram–диск и показывать большие показатели по скорости диска, но работать с него будет нельзя, тк данные также будут теряться на каждой перезагрузке. В тестах мы оценивали реальный сценарий: пользователь заказывает облачный сервер, устанавливает на него свое приложение и запускает. Представьте себе интернет-магазин, который узнает, что его данные будут стерты на каждой перезагрузке… Поэтому сравнение является корректным.
>… как самый дорогой в AWS, ага.
Посчитайте с другими регионами. Разница в несколько тысяч рублей погоды не сделает, когда общая разница в цене в разы и исчисляется десятками тысяч рублей. В нашем облаке единая цена для всех открытых для регистрации регионов.
>В AWS/Azure вы один раз настраиваете машину и в любой момент за пару минут поднимаете хоть с десяток _идентичных_ машин.
В InfoboxCloud присутствует аналогичная возможность клонировать облачные серверы и создавать шаблоны из них. И также можно сделать это не только через панель управления, но и через api
A какой смысл в их тестировании? При каждой перезагрузке данные с них пропадают. В InfoboxCloud все дисковое пространство покрывается SSD–кешем и не только не обнуляется, но и реплицируется, обеспечивая надежность хранения данных. Облачные сервера нужны не только для того, чтобы их тестировать, но и чтобы работать с ними. Сервер, на котором уничтожаются данные на каждой перезагрузке не подходит для хранения данных. Сравнивать нужно сравнимое. Никто не мешает в InfoboxCloud подключить ram–диск и показывать большие показатели по скорости диска, но работать с него будет нельзя, тк данные также будут теряться на каждой перезагрузке. В тестах мы оценивали реальный сценарий: пользователь заказывает облачный сервер, устанавливает на него свое приложение и запускает. Представьте себе интернет-магазин, который узнает, что его данные будут стерты на каждой перезагрузке… Поэтому сравнение является корректным.
>… как самый дорогой в AWS, ага.
Посчитайте с другими регионами. Разница в несколько тысяч рублей погоды не сделает, когда общая разница в цене в разы и исчисляется десятками тысяч рублей. В нашем облаке единая цена для всех открытых для регистрации регионов.
>В AWS/Azure вы один раз настраиваете машину и в любой момент за пару минут поднимаете хоть с десяток _идентичных_ машин.
В InfoboxCloud присутствует аналогичная возможность клонировать облачные серверы и создавать шаблоны из них. И также можно сделать это не только через панель управления, но и через api
В амазоне есть чисто ssd инстанс например i2.xlarge.
Вот что пишет сам амазон
I2 Instances are the next generation of Amazon Elastic Compute Cloud (Amazon EC2) storage-optimized high I/O instances based on solid-state disk (SSD) technology. They’re capable of delivering more than 365,000 random read Input/Output Operations Per Second (IOPS) across eight 800GB SSD storage volumes.
I2 Instances are the next generation of Amazon Elastic Compute Cloud (Amazon EC2) storage-optimized high I/O instances based on solid-state disk (SSD) technology. They’re capable of delivering more than 365,000 random read Input/Output Operations Per Second (IOPS) across eight 800GB SSD storage volumes.
33 тыс. руб. в месяц во Франкфурте + 22 т.р. за трафик. Это за инстанс с 1 диском на 800 гб
И всё равно системный диск на ней будет EBS. Так что тесты на рутовом диске проводить бессмысленно.
>A какой смысл в их тестировании? При каждой перезагрузке данные с них пропадают.
Смысл этих дисков в том, что они используются под то, что нужно. на них не стоит система, на них хранятся данные. если машина выключается, то локальные данные с неё уже не нужны. Всё остальное время это и есть тот самой быстрый дисковый массив для работы. Не бывает операций на хранение (архивацию) данных, шибко чуствительных к IO. Это всегда кэш, tmp и прочее. Слить потом в персистентное хранилище не проблема. Так что тест системного (сетевого) диска это странная чушь.
Сервер, на котором уничтожаются данные при перезагрузке подходит для чего угодно, что не хранит данные, а должно их быстро принять/обработать/отдать. Та же cassandra на него идеально ложится. Тот же elasticsearch. Да любой кластерный софт с репликациями и шардингом будет прекрасно жить, не теряя ничего и автоматически масштабируясь при изменении количества машин.
Я понимаю, что вы так мощно рады, что запилили такой прекрасный быстрый SSD-кэш, что пытаетесь теперь полить всех кругом фекалями, но всё же стОит немножко отдавать себе отчёт, что бывают разные области применения. И бывают разные требования. По мне так схема сетевой+эфемерный диск в AWS/Azure логична и абсолютно оправдана. Локальный SSD это прекрасный способ получить гарантированную производительность, не подверженную влиянию сети и прочей инфраструктуры. Никто не мешает объединять эти SSD на EC2-машинах в raid и получать космические скорости.
Смысл этих дисков в том, что они используются под то, что нужно. на них не стоит система, на них хранятся данные. если машина выключается, то локальные данные с неё уже не нужны. Всё остальное время это и есть тот самой быстрый дисковый массив для работы. Не бывает операций на хранение (архивацию) данных, шибко чуствительных к IO. Это всегда кэш, tmp и прочее. Слить потом в персистентное хранилище не проблема. Так что тест системного (сетевого) диска это странная чушь.
Сервер, на котором уничтожаются данные при перезагрузке подходит для чего угодно, что не хранит данные, а должно их быстро принять/обработать/отдать. Та же cassandra на него идеально ложится. Тот же elasticsearch. Да любой кластерный софт с репликациями и шардингом будет прекрасно жить, не теряя ничего и автоматически масштабируясь при изменении количества машин.
Я понимаю, что вы так мощно рады, что запилили такой прекрасный быстрый SSD-кэш, что пытаетесь теперь полить всех кругом фекалями, но всё же стОит немножко отдавать себе отчёт, что бывают разные области применения. И бывают разные требования. По мне так схема сетевой+эфемерный диск в AWS/Azure логична и абсолютно оправдана. Локальный SSD это прекрасный способ получить гарантированную производительность, не подверженную влиянию сети и прочей инфраструктуры. Никто не мешает объединять эти SSD на EC2-машинах в raid и получать космические скорости.
>если машина выключается, то локальные данные с неё уже не нужны
И тут Amazon решил перезагрузить все хосты
а потом отключил ненадолго дата-центр.
Смысл этого комментария не в том, чтобы показать, что Amazon плохой. Такая ситуация возможна в любом облаке. Смысл в том, что надеяться, что ваш сервер никогда не будет перезагружен без вашего желания, не следует. А т.к. данные на SSD дисках Amazon M3 удаляются при перезагрузке — такой инцидент для данных может стать фатальным. Поэтому строго не рекомендуется хранить данные на таких дисках в Amazon и Azure. Это не безопасно!
И тут Amazon решил перезагрузить все хосты
а потом отключил ненадолго дата-центр.
Смысл этого комментария не в том, чтобы показать, что Amazon плохой. Такая ситуация возможна в любом облаке. Смысл в том, что надеяться, что ваш сервер никогда не будет перезагружен без вашего желания, не следует. А т.к. данные на SSD дисках Amazon M3 удаляются при перезагрузке — такой инцидент для данных может стать фатальным. Поэтому строго не рекомендуется хранить данные на таких дисках в Amazon и Azure. Это не безопасно!
>а должно их быстро принять/обработать/отдать
такую задачу гораздо лучше и быстрее решает Ram диск. Заказывая инстанс пользователь может подумать, что он покупает обычный облачный сервер с SSD, а на деле все не совсем так: данные на SSD хранить не безопасно
такую задачу гораздо лучше и быстрее решает Ram диск. Заказывая инстанс пользователь может подумать, что он покупает обычный облачный сервер с SSD, а на деле все не совсем так: данные на SSD хранить не безопасно
Заказывая инстанс пользователь может подумать
Если пользователь не в состоянии прочитать документацию по сервису, который он собирается оплачивать — то да, лучше ему впарить что-то другое.
Если пользователь не в состоянии прочитать документацию по сервису, который он собирается оплачивать — то да, лучше ему впарить что-то другое.
> Локальный SSD это прекрасный способ получить гарантированную производительность, не подверженную влиянию сети и прочей инфраструктуры
>Сервер, на котором уничтожаются данные при перезагрузке подходит для чего угодно, что не хранит данные
В InfoboxCloud вы можете использовать сервера надежно и безопасно и для того, что хранит данные. Они не уничтожаются при перезагрузке и многократно реплицируются в отказоустойчивой распределенной системе хранения виртуальных машин Cloud Storage.
>Сервер, на котором уничтожаются данные при перезагрузке подходит для чего угодно, что не хранит данные
В InfoboxCloud вы можете использовать сервера надежно и безопасно и для того, что хранит данные. Они не уничтожаются при перезагрузке и многократно реплицируются в отказоустойчивой распределенной системе хранения виртуальных машин Cloud Storage.
результат тестирования в московской локации InfoboxCloud прямо сейчас
Можно провести новое тестирование: сегодня в Azure появилось ожидаемое Premium-хранилище на SSD
weblogs.asp.net/scottgu/azure-premium-storage-remoteapp-sql-database-update-live-media-streaming-search-and-more
Premium Storage disks provide up to 5,000 IOPS and 200 MB/sec throughput depending on the disk size. When you create a new premium storage disk you get the option to select the disk size and performance characteristics you want based on your application performance and storage capacity needs.
You can maximize the performance of your VMs by attaching multiple Premium Storage disks to them (up to the network bandwidth limit available to the VM for disk traffic).
weblogs.asp.net/scottgu/azure-premium-storage-remoteapp-sql-database-update-live-media-streaming-search-and-more
Premium Storage disks provide up to 5,000 IOPS and 200 MB/sec throughput depending on the disk size. When you create a new premium storage disk you get the option to select the disk size and performance characteristics you want based on your application performance and storage capacity needs.
You can maximize the performance of your VMs by attaching multiple Premium Storage disks to them (up to the network bandwidth limit available to the VM for disk traffic).
XaocCPS Спасибо, Владимир, непременно сделаем это в будущем. Как вы считаете IOPS? Публикация методики расчёта позволила бы проводить более точное сравнение. Без указания методики измерения эта величина не говорит почти ни о чем. Например, в тесте SQLIO наши локации набрали более 15000 iops (тест SQLIO разработан в Microsoft). И как именно вы определяете скорость в MB/s. Измеряете линейную запись данных? Результат в InfoboxCloud составляет 730 MB/s на момент тестирования и доходит до 1Gb/s и выше.
Sign up to leave a comment.
В InfoboxCloud запущено Enterprise SSD–кеширование. Сравнительные тесты с Amazon EC2 и Windows Azure