Существуют ли в природе облачные хостинги, представляющих несколько территориально разделённых нод в виде одного сервера?
Периодически изучаю тему облаков. Судя по всем определениям, облака — это некие сферические кони в вакууме, которые как-то (без разницы как) решают сложные технические проблемы создания распределённых систем, и предоставляющих сервис пользователю на более высоком логическом уровне. Что там внутри облаков, как они работают — пользователя волновать не должно, на то оно и «облако», а не «набор из бубна, чешек и коврика для танцев».
Однако на деле мы пока видим либо откровенную профанацию (когда обычные dedicated- и VPS-хостинги с мгновенной активацией используют слово «cloud» в рекламных целях), либо конструкторы, где более высшего логического уровня нет (Amazon — нужно изучить все его API, чтобы собрать всё воедино, + во всех сервисах есть ньюансы).
Был момент, когда я было обрадовался, найдя vps.net — думал, что в инстанс можно объединять ноды из разных городов. Ан нет — этого делать нельзя, это всего лишь vps под красивым соусом.
P. S. Облачными хостингами интересуюсь не потому, что у меня какие-то мегахайлоад сервисы, а потому, что хочется распределённости для надёжности и скорости.
P. P. S. Нода — минимальная виртуальная единица, которой оперирует облачный хостинг, кусок компьютера. Инстанс — готовая, собранная сущность, отдающая вебсайты.
«существуют ли хостинги, готовые объяснять клиенту, почему задача поддержания актуальной информации на двух географически разнесенных узлах ведет к ухудшению производительности и где они берут клиентов, готовых это терпеть?»
Никто не мешает спроектировать распределённое приложение «прослойка для популярных веб-приложений и фреймворков». Напроектировали же бурды всякой на Амазоне и Ракшаке.
Что значит прослойка в вашем видении? Супердистрибутив Джоомла Клустер Эдишн? Вордпресс Дистрибутед?
Чтобы вы поставили на них свои расширения, как прочитали в книжке «Джумла за 21 день» и все развалилось?
Я не имею ввиду лично вас и конкретно джумлу, но вы должны понять, что при коммерческой эксплуатации люди захотят это все сделать. Иначе они бы прекрасно обошлись бы распределенным и устойчивым narod.ru.
Раз какую-то услугу найти нелегко, значит есть объективные сложности с ней или с её окупаемостью.
Раз такую услугу найти нелегко, это на практике значит, что лепить слово «Cloud» на обычные VPS и дедик не то, чтобы легче — а и вовсе коммерчески выгодно.
Кстати — рекомендую статью товарища ниже, он как раз в теме и очень хорошо разжевал, что щас происходит в области cloud и «cloud» computing.
ЗЫ: прослойка не в движках. Это убого — именно по тем причинам, которые ты приводишь. ДА и как это может помочь, если у меня 3-4 поп. движка, + какие-то свои совершенно разные бульдоги и носороги?
Я говорю о прослойке между физическими серверами и движками. Т. е. LAMP Cloud Edition.
Тогда я все уже изложил в первом сообщении.
Чтобы оказывать приснившуюся тебе коммерческую услугу, нужно быть уверенным, что любой произвольный запрос на обновление данных (я не только об sql говорю) приведет к согласованному изменению на хранилище в целом. Любой удаленный компонент должен получить те же обновления еще до того как локальный sql-сервер вернет ответ скрипту. На передачу данных между разнесенными узлами требуется время.
Значит, в общем случае, на облаке будет работать медленнее чем на единичном сервере.
Ну и зачем все это нужно клиенту? Кто туда пойдет?
Насколько я могу заметить, общее мнение для частных проектов — просто покупать хороший хостинг в хорошем датацентре. Сутки простоя в год многие легко терпят.
В принципе, я еще могу себе представить, одностороннюю репликацию данных на запасной сервер-дублер, который просто ждет своего часа. Репликация работает асинхронно и никуда не спешит. В такой схеме клиент должен быть предупрежден что может потерять часть данных. И это даже неглупый технарь вполне может построить из подручных материалов.
Но будет ли это пользоваться коммерческим успехом?
>а потому, что хочется распределённости для надёжности и скорости.
как это часто бывает — «выбери любые два».
1.распределенность + надежность — нет скорости. уже описал.
2.надежность + скорость — значит нужно держать сервера рядом и соединять прямым проводом.
3.распределенность + скорость — нет надежности: неизвестно как поведет себя произвольный не подготовленный движок, спроектированный для работы на одном сервере.
то есть, если ты изначально хотел.надежность+скорость — тебе нужен виртуальный хостинг с односторонней репликацией файлов через drbd и односторонней репликацией mysql.
Это добра навалом на рынке виртуального хостинга. Даже поэффективнее чем REMUS будет.
Такие конфигурации описаны в литературе и особых проблем при построении не составляют.
арендуете несколько одинаковых «облаков» в разных точках и распределяете трафик через какой-нибудь CDN типа Akamai. Может кто-то и догадается это сделать «из коробки», чем не идея для стартапа?
Термин «Облако» используется как метафора, основанная на изображении Интернета на диаграмме компьютерной сети, или как образ сложной инфраструктуры, за которой скрываются все технические детали.
А ты предлагаешь противоположное тому, о чём вопрос — как не собирать из конструктора что-то там.
Т. е., по-русски говоря, должно быть так: я нажал «купить», залил движок — и всё. На 1м или миллионе серверов оно, как осуществляется целостность данных — это уже не моя забота. Вот это — облако.
Батенька, вы — идеалист-максималист. Я предложил решение вашей проблемы, да оно требует включить мозг и засучить рукава. Как сделаете для себя — потом будете продавать другим, еще и миллион баксов заработаете.
Multiple Locations – Amazon EC2 provides the ability to place instances in multiple locations. Amazon EC2 locations are composed of Regions and Availability Zones. Availability Zones are distinct locations that are engineered to be insulated from failures in other Availability Zones and provide inexpensive, low latency network connectivity to other Availability Zones in the same Region. By launching instances in separate Availability Zones, you can protect your applications from failure of a single location. Regions consist of one or more Availability Zones, are geographically dispersed, and will be in separate geographic areas or countries. The Amazon EC2 Service Level Agreement commitment is 99.95% availability for each Amazon EC2 Region. Amazon EC2 is currently available in four regions: US East (Northern Virginia), US West (Northern California), EU (Ireland), and Asia Pacific (Singapore).
В местной терминоголии instance — это приблизительно то, что Вы обзываете нодой. Кусок компьютера, на котором крутится кусок сервиса. Естественно, instances должны быть separate, иначе никакой отказоустойчивости не будет.
Минутку, а как Вы хотите?
У вас есть веб-сервис. Вы запускаете несколько экземпляров в разных локациях. Вы хотите, чтобы был запущен ровно один экземпляр? Тогда не получится избыточной надёжности.
Я хочу, чтобы автоматом для меня осуществлялась вся работа над целостностью данных. В случае со статикой так и делается на всяких там CDN-сервисах.
Например, примитивный пример: все гугл-сервисы бегают под Google FS, в которой каждый кластер хранится хотя бы на 3х серверах. Т. е. если я юзаю какой-нить Google-сервис, за целостность я спокоен.
Мы говорим про storage, или про application?
У того же Amazon S3, чтоб далеко не ходить, поддерживается storage redundancy:
Objects are redundantly stored on multiple devices across multiple facilities in an Amazon S3 Region. To help ensure durability, Amazon S3 PUT and COPY operations synchronously store your data across multiple facilities before returning SUCCESS. Once stored, Amazon S3 maintains the durability of your objects by quickly detecting and repairing any lost redundancy. Amazon S3 also regularly verifies the integrity of data stored using checksums. If corruption is detected, it is repaired using redundant data. In addition, Amazon S3 calculates checksums on all network traffic to detect corruption of data packets when storing or retrieving data.
storage — это не статика!
storage — это информация в базе данных.
По моему опыту, доступ к данным в БД — это главная проблема в распараллеливании веб-приложений. Потому что собственно сервлеты всякие можно запускать на разных машинах поштучно для каждого пользователя.
Купите лицензию на софт у www.scalemp.com и размещайте эти ноды по всему миру где хотите, хотя я думаю каналы будут в этом случае самым узким местом…
А для чего Вам это нужно, если не большой секрет ??
Средний
Простой
Средний
