[Kirya]

У CDN виртуализация может быть, а может и не быть. Так-что строго формально быть облаком не обязано. Кроме того, уровень абстракции SaaS в "облаках" несколько больше, чем в довольно узко заточенном CDN. CDN больше упирает на транспорт, пусть и хитро оптимизированный внутренними инструментами, в то время как "облака" больше ориентированны на прикладной уровень, на хостинг именно приложений. Можно, конечно, распределённую маршрутизацию с кэшированием тоже назвать приложением, но если сравнивать, к примеру, с облачным офисным пакетом, то уже видна разница между ними. Ну и потребители у этих двух сервисов очень разные.

 

Кстати, CDN ещё и не обязаны иметь публичный доступ, вообще-то. Могут, но не всегда имеют.

Хм, вон оно как, Михалыч...

А mainframe-ы IBM, собранные в кластер, 60-х годов прошлого века, с подключенными текстовыми терминалами через dial-ap, тоже SaaS ?

Виртуализация налицо, автоматическая дистрибьюция тоже присутствует, возможность совместной работы на прикладном уровне, связь попроще правда и полное отсутствие графики, но когда это останавливало гуру...

Изменено 1 августа, 2011 пользователем Kirya

[vIv]

Ну на самом деле всё компьютеры, да. Но есть ноутбуки! :-)

 

А mainframe-ы IBM, собранные в кластер, 60-х годов прошлого века, с подключенными текстовыми терминалами через dial-ap, тоже SaaS?

Киря, терминал - это очень конкретная клиентская железка. Это не сервис, а терминальный доступ. А вот с Chrome OS вообще фиг пойми, - вроде, и облачное, а по сути даёт функцинальность терминального доступа.

[Kirya]

Я понял, т.е SaaS это терминальный графический доступ к территориально распределенному кластеру через Ынтернет ?

Изменено 1 августа, 2011 пользователем Kirya

[vIv]

Я понял, т.е SaaS это терминальный графический доступ к территориально распределенному кластеру через Ынтернет ?

Ну если у тебя в свойствах этого доступа деньги берутся за какой-то сервис, то в принципе да. Если просто за некий RDP, где ты сам себе софт ставишь, - то нет. Хотя есть и бизнес тупо "винды с офисом на хостинге". Кроме того, вот именно самого терминального доступа в облаках может и не быть, зато может быть, к примеру, API поиска, как у Гуглов.

[Kirya]

Дак это обычный клиент-серверный хостинг приложений с web-мордой получился , известный ещё с времён изобретения Тимоти Бернерсом-Ли WWW.

[vIv]

Киря, всё суть компьютеры с сетевыми интерфейсами. Но есть ноутбуки! ;-)

В облака НЕ входит веб-морда. Зато входит активное использование виртуализации/балансинга, часто с территориальным разнесением. Отсюда ряд технических нюансов типа возможного отката состояния на короткий квант времени и повышенной надёжности, встроенной лёгкой масштабируемости on-demand (ты попробуй мощность дедика раз в двадцать увеличить), некоторые нюансы с адресацией (ДНС, а не IP). Технически это всё коктейль из известных решений, - о чём пишет Прохожий, - но будучи смешанным в коктейль этот набор решений даёт некую потребительски понятную сущность, позволяет быстро понять в общих чертах, о чём идёт речь.

[Kirya]

Феерический бред...

Когда ты наконец откроешь wikipedia, и наконец прочитаешь, статью про SaaS ?

http://en.wikipedia....re_as_a_service

Ведь я оттуда примеры таскаю :)

 

SaaS - это в первую очередь МАРКЕТИНГОЕ определение методов взятия платы работы за ASP хостинг..

А техника-виртуализация, кластеризация, балансинг и прочее, это следствие, а не первопричина,

ибо на подавляющем большинстве приложений это единственный метод масштабирования.

Теперь понимаешь, что Прохожий-то на самом деле суть процесса показал ?

Изменено 1 августа, 2011 пользователем Kirya

[wanderer_from]

SaaS - это в первую очередь МАРКЕТИНГОЕ определение методов взятия платы работы за ASP хостинг..

Киря, ты так говоришь, как-будто МАРКЕТИНГ это что-то плохое.

 

Ну реально трудно объяснить местячковому CIO с незаконченным техникумом им. Ползунова, что такое "распределенная виртуальная инфраструктура". Он дурацкие вопросы начинает задавать типа, а как он счет-фактуру на дискетку скачает. А рисуешь ему облачко из которой одна стрелочка уходит в к нему в офис, а другая в налоговую - у него сразу все сходится. Абстракция и упрощение правят миром.

 

Относительно WEB2.0 так же было - чего только к нему не приплетали, но ить устаканилось же. Все теперь понимают, что Интернет это не Йаху, а вовсе и Вконтакик. Как-то так... :)

[vIv]

Феерический бред...

Когда ты наконец откроешь wikipedia, и наконец прочитаешь, статью про SaaS ?

http://en.wikipedia....re_as_a_service

SaaS - это в первую очередь МАРКЕТИНГОЕ определение методов взятия платы работы за ASP хостинг..

Киря, ты путаешь таксометр с таксопарком, а их обоих с тарифом ;-)

"Облака" - это "такси". ОБЫЧНО в такси есть таксометр, который считает стоимость поездки по тарифу. НО в слове "такси" есть ещё некий ряд других предполагаемых клиентами свойств.

[Прохожий]

Технически это всё коктейль из известных решений, - о чём пишет Прохожий, - но будучи смешанным в коктейль этот набор решений даёт некую потребительски понятную сущность, позволяет быстро понять в общих чертах, о чём идёт речь.

Вив, вместо того, чтобы пытаться тут притянуть искусственные сущности - иди сделай что-то полезное :) Не даром один известный тебе персонаж внес "облачные вычисления" в список запрещенных к употреблению слов ;)

 

Абстракция и упрощение правят миром.

Именно! Но вот только упрощение без абстракции. При этом это являются основой брендинга, маркетинга и, зачастую,как это не странно, человеческих взаимоотношений. Потому что даже в них проще нарезать всю совокупность людей на понятные "сегменты" по нескольким основным осям, а не вникать в уникальность разума и души.

 

Киря, ты путаешь таксометр с таксопарком, а их обоих с тарифом ;-)

Гы, вот как раз Киря ничего не путает, это ты в маркетинге заплутал и пытаешься отстоять факт существования несуществующей сущности.

[chainick]

А поясните чайнику, вот я VDS у конторки арендую, на нем у меня винда установлена и я в ней по рдп работаю. Это облачный сервис и если да, то где именно (винда, ВДС)? а то я запутался уже с этими аббревиатурами.

[vIv]

Нет. Вот если бы твой провайдер (ты) обеспечивал тебе доменное имя, за которым бы прятались десятки VDS для RDP, причём с балансингом между ними, - то это можно было бы подтянуть под термин "облака". А если сервер один, то не, не катит. Кроме того, тупо терминальный доступ - это какбэ не совсем сервис. Где сама услуга, где твой прямой профит? Если только снижение затрат на резервирование, - то это не совсем облака, тут затраты на доступ через паблик сожрут все профиты. Должно быть что-то, что ВЫГОДНО покупать через паблик на чужой виртуализированной платформе.

[kostich]

vIv, а мне всегда казалось что облака это системы с оплатой за ресурсы, где вовсе необязательно что-то балансить. т.е. это такая виртуализация, в которой ресурсы выделяются динамически. когда у меня нет нагрузки, то моё облако очень маленькое... когда есть, то облако растёт. непомню уже максимальные характеристики на один процесс, но где-то можно было кратковременно выжирать под 100 гиг оперативы... друзья покупали как-то для девелоперов, а потом мигрировали на железку физическую.

 

А если сервер один, то не, не катит.

 

а если на нем полтерра памяти и надцать скоростных ядер?

[chainick]

Вив, го хостер утверждает, что у него сотни серверов с балансингом и крутым SAN для хранения.

 

Или вот пример, мы предоставляем своим региональным представительствам почтовый сервис на иксчендже, они только пожключаются клиентами и местные админы рулят директорией своих доменов. Но у нас нет балансинга и прочего. Хотя, из терминологии - это чистый саас.

 

В общем, я тоже склоняюсь к точке зрения, что это больше маркетинг, чем новый виток технологии.

[kostich]

chainick, виток в р-не инфинибенд-а, когда по RDMA можно ЗАИМСТВОВАТЬ память соседних железок. т.е. у кого-то это технологически, а у кого-то чистый маркетинг про балансировку и бла бла бла... а так как можно заимствовать память, то для отдельных потоков/процессов можно заимствовать и процы... в итоге получаем какую-то такую растущую до каких-то больших пределов виртуализацию. линейности из-за атомиков никогда не будет.

[vIv]

vIv, а мне всегда казалось что облака это системы с оплатой за ресурсы, где вовсе необязательно что-то балансить. т.е. это такая виртуализация, в которой ресурсы выделяются динамически. когда у меня нет нагрузки, то моё облако очень маленькое... когда есть, то облако растёт. непомню уже максимальные характеристики на один процесс, но где-то можно было кратковременно выжирать под 100 гиг оперативы...

Вот тут всё очень близко, кроме самой оплаты. Самой оплаты может не быть в явном виде. А так, - да: это оторванная от физической реализации виртуалка, которая может масштабироваться от величин сильно меньше единицы физического сервера до тысяч единиц и больше, - по запросу, в том числе по запросу, например, скрипта (то есть без визита в офис и подписания договора). Побочный врождённый эффект, - она может масштабироваться не в одной точке пространства, то есть может быть территориально распределённой в ответ на запросы требуемой процессорной мощности.

 

А если сервер один, то не, не катит.

а если на нем полтерра памяти и надцать скоростных ядер?

Дедик? ;-)

[vIv]

Или вот пример, мы предоставляем своим региональным представительствам почтовый сервис на иксчендже, они только пожключаются клиентами и местные админы рулят директорией своих доменов. Но у нас нет балансинга и прочего. Хотя, из терминологии - это чистый саас.

Нифига! Вот если у вас на этом эксчендже будет хотя бы с пару десятков контор с виртуально независимыми серверами самого эксченджа (кстати, кажется, это возможно) и при этом крах/удаление одного/ряда аккаунта/-ов или аппаратных серверов никак не будет сказываться на остальных, - то да, будет облачный Эксчендж. Кстати, такие услуги уже оказываются. И Офис 365 тоже ;-)

[kostich]

Дедик? ;-)

 

причем тут дедик или VDS? суть в том, что тут тонкости перевода. они вбивали в мозг, что тем кому не надо покупать столько ресурсов можно купить облако, но отличие облака от VDS, в том, что ресурсы могут динамически массштабироваться за пределы физического сервера. суть массштабирования в лимитировании каких-то функций ОС. можно даже сказать это такое API к кластеру с билингом за использование ресурсов. любая линейно массштабируемая система строится по принципу сокращения атомарных операций. если пользователю запретить использовать какие-то атомарные операции, то он будет писать нормальный софт под систему распределенных вычислений. если брать CDN, работающие как реверс-прокси, то там атомарные операции возникают за счет использования авторизации, кук и разных сессий. т.е. нельзя взять чужой веб-сайт и массштабировать его при наличии атомиков. любая БД при наличии какого-то уникального индекса подразумевает атомарную операцию. само собой если нету атомиков, то CDN работающая как реверс-прокси даёт линейную массштабируемость. а если брать вычислительный ресурс похожий на VDS, который массштабируется, то там всё сложнее... это не веб-сервер, там так просто от атомиков не избавишься. есть системные вызовы, которые не могут без атомика выполняться. облако это все же маркетинговый термин, который подразумевает API и систему фин. учета для продажи какого-то массштабируемого ресурса выходящего за пределы физического сервера.

[vIv]

Вот с учётом в облаках на данный момент всё, скажем честно, "невнятно". Если померять доступность сервиса в процентах от времени ещё как-то можно, можно даже поинтегрировать какие-то поточные единицы по времени, то вот в операциях, насколько я это себе представляю, всё совсем нихрена непонятно.

[kostich]

и при этом крах/удаление одного/ряда аккаунта/-ов или аппаратных серверов никак не будет сказываться на остальных, - то да, будет облачный Эксчендж. ...

 

крах это из области HA или горячего резервирования. у меня одна из задачек сводилась к разработке системы, где надо было гарантированно отработать HTTP запрос. при сетевом сбое нельзя гарантировать подхват сессии и отработку её другим элементом вычислительного ресурса, хотя технически это было возможно... но ценник разработки в бюджет не вписывался. любая распределенная система может предоставлять какие-то гарантии в рамках SLA на определенные модули. так сказать нельзя гарантировать безсбойное мигрирование VDS-а, но можно гарантировать определенную целостность данных... когда придумают дешевое горячее резервирование оперативной памяти, то можно уже о чем-то говорить.

 

для примера приведу питание в обычной стойке, которое надо зарезервировать. вероятность возникновения КЗ в БП или проводе на уже работающих железках мала, т.к. разные автоматы на это отреагируют и вся стойка не пострадает, но для этого автоматы должны быть на каждой розетке каждого сервера + отдельные шнурки для двух-трех шнурковых БП с резервированием. только при наличии автоматов на каждой розетке можно что-то гарантировать. на практике у меня такого ни разу не случалось, но вероятность этого есть. знаю тех у кого случалось... при мне несколько раз втыкали шнуры с КЗ и в рамках одного блока вырубало всё, причем раза три такое было... один раз случилось после тестового включения сервера. таким образом получаем, что если мы хотим там что-то гарантировать, то тестовое включение серверов должно производиться не за тестовым столиком, а включением шнура в отдельную тестовую розетку на самой стойке... это давний спор, как раз когда речь шла за хорошее SLA для ДЦ. за свичи тут рассказывать не буду, расскажу лучше про файлопомойки большие... в системах с горячим резервированием из-за выхода из строя одной мамки рушится вся система.. там нет предохранителей на физику, там нет изоляции... вероятность мала, но мать на очень крутой системе при мне один раз ломалась...

 

из всего этого следует вывод, что гарантировать могут только на бумаге в рамках каких-то проведенных тестов... это не в контексте конкретно почты, т.к. там приложение по сути своё, которое заточено под это. в тех облаках которые аля большие VDS есть описанные SLA и гарантий там на самом деле мало, но на дисках всё останется... оживёт достаточно быстро, а то что было в памяти ясно дело исчезнет.

[kostich]

Вот с учётом в облаках на данный момент всё, скажем честно, "невнятно". Если померять доступность сервиса в процентах от времени ещё как-то можно, можно даже поинтегрировать какие-то поточные единицы по времени, то вот в операциях, насколько я это себе представляю, всё совсем нихрена непонятно.

 

продажа доступности это такой же маркетинг, как и продажа серверов с резервированным питанием. в предыдущем посте про питание отписал. забыл разве что сказать, что при КЗ на одном из входов в БП сервера падали целиком. я не помню железку уже, может быть такого и не должно происходить, но оно падало. тестировать железо смысла нет, достаточно поставить блоки с автоматом на каждую розетку. продажа доступности подразумевает какую-то компенсацию, в большинстве SLA копменсируется в объеме платы за период простоя, а где-то с каким-то незначительным бонусом. т.е. это маркетинг всё. как продают дисковое место и оперативную память понятно всем, но как продают CPU надо почитать просто.

[nastypetra]

"Облака" - это просто тренд такой, и всё, что могут, под этот тренд закрашивают.

[jab]

т.е. это маркетинг всё. как продают дисковое место и оперативную память понятно всем, но как продают CPU надо почитать просто.

 

Тиками продают. :-) Так же как, например, Cray продавал 40 лет назад. Более сложные биллинги на вычисления были у Bull и Data General afair.

 

Грубо говоря, облако отличается от мэйнфрейма только ценой и территориальной распределенностью. Все остальное тыщу лет в обед было изобретено.

[karpa13a]

а вот скажите как мне виртуалку завернуть на два физических сервера.

или только две виртуалки и в рамках текущего железа?

[kostich]

а вот скажите как мне виртуалку завернуть на два физических сервера.

или только две виртуалки и в рамках текущего железа?

 

там интересные схемы есть. первое это общая сетевая файловая система, без которой сложно что-то кластерное такое строить. отличие её от обычной файловой системы в DLM (распределенный менеджер блокировок). если мы расшарим 1 жесткий диск по SCSI в режиме RO на два сервера, то мы сможем им пользоваться без сетевой файловой системы. когда поднадобится на него записывать, то надо синхронизировать кэши чтения, кэши записи, файловые блокировки и всё остальное. у NAS-ов такого недостатка нет, т.к. они по тому же NFS предоставляют полный сервис. у NetApp были решения с массштабированием, но там не все так линейно как кажется. у NAS-ов минус по физическому подключению дальнейшему. это всё в контексте общей файловой системы. потом возникают вопросы с общей физической памятью, см. выше про инфинибенд и RDMA, а далее уже там таск-манагеры и прочее... но это такой физический кластер уже получается. в тех облаках что я видел по большей части API для линейного массштабирования, т.е. расти конкретной задачей за рамки одного физического сервера нельзя. у них там какая-то динамическая миграция есть, т.е. когда ресурсов надо совсем много, то прозрачно мигрируешься на сервер более большей мощности. мои клиенты брали пул из облаков, между которым был какой-то автоматический балансинг. по сути кучу динамически-массштабируемых VDS-ок... но там как-то укоцано всё под совсем уже вольные задачи.

 

теперь если мы не берем VDS, а хотим сделать именно линейно массштабируемый хостинг, т.е. распределенный хостинг с минимум гемора для клиентов. мы должны запретить писать приложениям на диск или сделать эту операцию очень медленной. лучше конечно запретить. про деплой описывать не буду, про выкладку данных тоже. получаем, что клиентские приложения на пехапе, питоне и т.д., могут одинаково работать на всех серверах. с такими облаками тоже сталкивался + разрабатывал. в плане фронт-а клиент может массштабироваться до очень больших каких-то размеров, но пхп без БД ему не надо... далее к нему цепляют массштабируемую базу, разные массштабируемые приблуды. если клиенту нужна общая файловая шара с возможностью записи, то она отдельно идет. приложения не использующие запись на диск массштабируются линейно, а все остальное будет тупить из-за файловой шары + нельзя разнести по географии.

 

пысы. в хостингах не надо 1 процесс массштабировать за пределы физического сервера... потом не надо синхронизировать процессы в рамках всех серверов. для синхронизации приложений либо БД (а там уникальный индексы роль атомиков выполняют + локинг таблиц), либо файловая система.