В рамках стратегии по модернизации ИТ-системы США Белый дом опубликовал Federal Cloud Computing Strategy - 43-страничный документ (читать целиком), в котором дается определение облачным вычислениям, рассказывается о преимуществах технологии, включая примеры внедрений, и предлагаются рекомендации по внедрению облачных вычислений в государственный аппарат. По словам Вивека Кундры (Vivek Kundra),...

Читать статью на CNews

Гыгык. Кризис клюнул в попу - сразу про эффективность в ИТ вспомнили. ПКкапец. :lol:

у них есть 43 страничный документ...
А у нас водопровод! Вот!
и еще:
А из нашего окна Площадь Красная видна!

В слове "видна" Вы буковки местами поменяли. :D
Правильно будет: "А из нашего окна Площадь Красная Bинда"
Или не, все равно как то не так, слово "винда" 2 раза в одном предложении.
Давайте так, "А из нашего Окна :o (С)Микрософт"

выкуси пендосня тупая!
а у нас будет национальная стратегия развития концепции инновационных заоблачных вычислений правительства России вперед!

Однако, первая реакция почтенной публики - "Палата № 6" :angry:

При том, что тема действительно более чем актуальная. Если еще кто не понял - "облачная жизнь" уже началась и это тренд не на год и не два. Это наше будущее и кое в чем уже настоящее на ближайшие 10 - 15 лет. Все заявленные в этой проходной заметке параметры более чем реальны (по нашему опыту, так даже занижены). Вашингтонский обком - он далеко, но даже для "маленького российского предприятия" тема более чем актуальны - снизить в разы расходы и повысить в разы скорость внедрения ИТ. Вот это и есть инновация в чистом виде - как "защитная реакция экономического субъекта на неблагоприятные внешние условия".

Чем зубы скалить, лучше бы мозги включили....

Включили

Как аппарат будет работать быстрее, если серверы и сейчас простаивают?
IMHO у них тоже умеют пилить. 80млрд$ -- красивая сумма.

Приходим мы к клиенту (обычная российская компания). У них все хозяйство крутится на 14 серверах (как положено - по серверу на задачку). Загрузка - 10-15%. Заменили на шасии IBM BladeCenter S с ДВУМЯ серверами-лезвиями. Поставили на них VMware и теперь ВСЕ задачи в форме виртуальных серверов крутятся на ДВУХ серверах-лезвиях с загрузкой 50%. Половинной загрузки добивались специально, чтобы в случае останова (планового или аварийного) одного из лезвий все задачки автоматом переползли на работающее лезвие и народ "не заметил потери бойца".

Куда клиент дел 14 ВЫКЛЮЧЕННЫХ ящиков - мы не спрашивали. Клиент счастлив до крайности - на одной электроэнергии (7 руб/квт) отбили все затраты за 6 месяцев.

А теперь представьте все то же самое, но в пределах государства. Потенциальный противник уходит в глубокий отрыв, а мы и не чухаемся...

Только зубы скалим...

физические сервера загружены в среднем на 30%, суть в том, что использование виртуализации, например, поможет снизить количество физических серверов, а это снизит TCO.
а быстрее и эффективне - скорость развертования, упрощенный BCP\DR и масштабируемость как минимум.

Статейку-то надо бы до конца прочитать.


Читай между строк: "Юзер, если ты дурак, то никакие суперИТ тебе не помогут, а карман мы тебе облегчим."

Не только статейку до конца прочитали, но и не поленились скачать и прочесть (пока по диагонали) документ - "виновник торжества". А также поисследовать ссылочки в этом документе (их там много и есть очень интересные, особенно когда начинаешь также изучать биографии авторов).

Процесс внедрения технологий виртуализации у типового клиента условно делится (по характеру и размеру выгод для клиента) на три основных этапа:
1) консолидация - все железные сервера сконвертировали и упаковали на хосты под управлением гипервизоров. Средний по рынку коэффициент консолидации - 1:10. Бывает и ниже (если исходные сервера были хорошо нагружены), бывает и выше - до 1:100 (купили под проект виртуализации новую мощную железку и переложили на нее содержимое множества старых слабеньких серверов - обычно это бывает у телекомоператоров). Здесь главное достижение - снижение общих расходов на замену устаревающего оборудования и последующая экономия на обслуживании (от меньших расходов на лицензирование того же WinServer, до снижения расходов на эл-во и сокращение числа сисадминов (на железной инфраструтуре один админ управляет до 10 машин, на виртуализованной - до 100).
2) Высокая доступность - виртуальные сервера очень легко переносить с хоста на хост. В том числе автоматически - при сбоях. Соответственно - для клиента система с надежность 24/7 становится дешевле в разы (по сравнению с чисто аппаратным решением и специализированным ПО). Фактически - теперь доступна маленькой конторе с двум хостами на базе офисных ПК и лицензией VMware vCenter Essentials Plus (стоимость вопроса 3000 долл). Посчитайте потери даже маленького бизнеса от остановки из-за сбоя сервера хотя бы на день. (Представьте туристическое агентство в пик сезона)
3) Виртуализация рабочих мест - новая реинкарнация того, что раньше называлось терминальный доступ. Но на качественно более высоком уровне - с точки зрения удобства. Экономия - если в обычных условиях ПК "живет" 3 года (потом по хорошему надо менять/апгрэйдить), то в новой инфраструктуре срок нормальной жизни ПК увеличивается до 5 - более лет (фактически до физического износа). Мораль - сокращение вдвое расходов на амортизацию. Это не считая экономий на эл-ве и стоимости текущего обслуживания (централизованно хранимые и управляемые образы рабочих мест контролируются на порядок лучше и быстрее, чем индивидуальный бардак на каждом рабочем месте)

Согласен с тем, что это "новая жизнь". И если для клиента разборы в ИТ-технологиях не есть основная цель в жизни, то без внешних профессионалов не обойтись. Но тема того стоит:

- Средний срок полной окупаемости проекта виртуализации - от 3 - до 6 месяцев.
- Выигрыш в ROI/TCO - в разы. Есть инструменты объективного и точного моделирования экономики таких проектов. Их использование входит в обязательную программу тех, кто занимается этим профессионально.

Представленные вами этапы отражают аппаратный аспект. Если до ЦОДа выделенка и софтом управляет специалист по софту, то какая разница от обычного аутсорса? Только в принадлежности железяк? Но здесь сразу возникают вопросы по гарантиям производительности в пиковый период. Разброс в нагрузке в пиках и вне его может отличаться на порядок. Я с такой ситуацией сталкивался при сайзинге железа на проект. Решение - железо приходится брать в расчете на пики. Пиковая нагрузка вызывается, как правило, внешней отчетностью, а, следовательно, сшибание лбами нескольких контор весьма вероятно.
Другой блок вопросов связан с работоспособностью на виртуале софта и с синхронизацией его апгрейдов, если это не офисный ширпотреб, а настоящий бизнес-софт. По опыту сопровождения систем типа SAP, проблема апгрейда очень тяжелая и может решаться только подготовленными специалистами, хорошо разбирающимися в конкретном бизнесе конкретной конторы.
Ну, а ценность для "маленького бизнеса" - это тоже вопрос. Ему ЭТО действительно нужно? Быть может без понтов он обойдется записной книжечкой и калькулятором? В крайнем случае ноутбука хватит за-глаза. Приходится вертеться и много двигаться, чтобы выжить. С буком намного удобнее.

почитал бы что вкладывается в понятие "облачные вычисления".

Ну, почитал.
Облачные вычисления

И что? Об чём и речь.

если у тебя всё еще возникают поднятые тобой вопросы, то читай до тех пор пока вопросы не пропадут.

Восточная мудрость гласит: "Сколько ни повторяй халва, халва ..., во рту сладко не станет"
Облачные теоретики бесконечно далеки от прагматичного бизнес-народа. Их мотив прозрачен до неприличия. А Кундра, тем не менее,

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

OldMan47

облачные теоретики немного более адекватны и технически подкованы (как выясняется) чем облачные паникёры-теоретики.

Ну вообще говоря при отсутсвии жёстких требований со стороны SAP-а на IO он прекрассно живёт на VMWare ESX.... А про связь виртуализации и проблем апгрейда софта я, если честно вообще не уловил...



Есть у меня друг, сис. админ.... Были у него пробелмы с бюджетом под ИТ - оборудование было нужно и под АД, и под то, и под сё... а не давали денег, точнее на то, что давали нужного кол-ва приличного железа не купишь - вот тут-то ему виртуализация очень пригодилась.

Сударь!
Так речь идет не технике забивания шурупов, а о приемлемости данной фичи серьёзному бизнесу с ГАРАНТИЕЙ компенсации потенциального ущерба. Оговорки типа "AS IS" и отнекивание от ответственности за ущерб от использования поделок - это детский лепет в стиле мелкомягких.
Что M$, что SAP на претензии к обломам и глюкам отвечают одинаково: "Вы не умеете пользоваться нашей самой лучшей в мире системой". И это в режиме tête à tête. А с кого спрашивать в балагане, именуемом "Интернет"?
Вопрос в целом совсем не технический, а сугубо правовой. Кто из облачных теоретиков и чем поручится за гарантии ненанесения ущерба?
Тезис о "технической подкованности облачных теоретиков" сродни совковому тезису "пассажиры для заполнения поездов". Нужна бизнес-подкованность и юридическая подкованность для гарантий бизнесу. И в целом Ваши облачные песнопения целесообразнее адресовать самому Кундре, чтобы он мог спать спокойно. :D

Для простоты рассмотрим обычное корпоративно-серверное решение: операционка + пачка прикладного софта. У нас это была солярка + пачка саповских компонент. В всем этом букете софта, все блоки которого ДОЛЖНЫ ВЗАИМОДЕЙСТВОВАТЬ, установлены жесткие требования по согласованию ВЕРСИЙ. Поэтому при апгрейде любого из них было небходимо тщательно проанализировать потребности в апгрейдах связанных компонент (и солярки тоже). Кроме этого, поскольку саповские модули это не просто инсталляция, но и частные бизнес-настройки, необходимо тестирование работоспособности настроек после наката патчей по ВСЕМ проапгрейденным компонентам. Бывали прецеденты, когда требования от бизнеса проапгрейдить некоторый блок давали нежелательные побочные эффекты в других компонентах. Напомню, что в этой заварушке завязаны и соляркины патчи. В результате иногда приходилось делать откаты патчей и тормозить апгрейд.
Таким образом, балансировка апгрейдов без прямого управления со стороны хозяина системы в принципе нонсенс.
Если теперь к этой простейшей системе добавим лишних "игроков" в виде облачных и прочих интернет-услуг и некоторого количества компаний, пользующихся ими, то система вообще становится неуправляемой из-за коллизий требований к версионности со стороны каждого из "игроков".
Сударь! Про сис.админовские проблемы такого рода можно долго плакать друг другу в жилетку. У меня тоже они были всегда. :( Полезным выходом был, тем не менее, только вариант, когда удавалось убедить шефа в необходимости создания полигона под конкретную юзеровскую задачу.

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

Фиксируем откат от сервиса «Программное обеспечение как услуга».
Рассматриваем сервис «Платформа как услуга».
Тройка первых вопросов:
1. Управление бэкапами. Своё по требованиям бизнес-логики или дяди Васи по технологии "from thumb"?
2. Пропускная способность каналов и их гарантированность работы. Для работы с OLAP крайне критичны обе позиции, для OLTP - особенно вторая, иначе бизнес встанет.
3. Синхронизация данных в гетерогенной ИТ-системе.
Это, по-Вашему, "притянутые за уши потенциальные проблемы"? Попробуйте доказать это топ-менеджерам компании, которые недосчитаются прибыли.

1. как хочешь, так и будет, только плати.
2. проблемы каналов не являются специфическими для облычных вычислений, нет смысла их сюда приплетать.
3. как захочешь, так и будет, только плати.


1. расскажи про свой опыт, а то выглядит как предположения.
2. часто ты про технологические ньюансы рассказываешь топ-менеджерам?
3. если обсуждаешь это с топ-менеджерами, накидай на вскидку анализ кост\бенефит, карту рисков. какими данными оперируешь на встречах? конец света не рассматриваешь?

Так деньги счет любят, и гарантии эффективности. Скупой платит дважды, а тупой постоянно. :D Если Ваши "облычные вычисления" - вещь в себе, мухи ("облычные вычисления") отдельно и котлеты (бизнес-приложения) отдельно, то вопросов нет, успехов Вам на ниве ИТ-самообслуживания. :+: Плати, плати, плати, ... Вот это и есть истинная подоплека "облычных вычислений", а не польза для юзеров. Очень напоминает сценку у гадалки.У Вас есть коммерческие предложения? Или просто ля-ля-ля?Разумеется! Когда надо объяснить суть предлагаемой технологии. У ключевых топов на последних проектах, в которых я участвовал, нормальная соображаловка.
Спасибо! Понял, Вы не в теме.
Сухой остаток. Сервис «Платформа как услуга» повисает ввиду превращения облаков в воздушные замки.

У нас и средств таких нет. Вообще облачные вычисления нужны. Огромная экономия на коммунальных услугах. Когда дойдем неизвестно. Хомяченко писал о шестом укладе , а мы еще в третьем.

ну амерканцы в своем репертуаре)) наверное на задней передаче постоянно))

это все теория притом США и так страна уже не та в которую стоит стремится!!!