Вообще говоря, футуролог с меня говенный. Утешает только то, что не только из меня, масса народа ошибалась в технических прогнозах. Поэтому я прогнозировать не берусь, а вот помечтать попробую. Собственно, на фантазии меня подвиг недавний визит в Крок, где мне и коллегам было показана облачная инфраструктура, уже очень близкая по качеству к коммерческому уровню и которая уже потихоньку продается. Одним из выводов, которые я вынес из общения, является то, что клиенты и крупные интеграторы не только прониклись ценностью централизованных моделей вычислений, но и пытаются перевести это понимание в практическую плоскость. Естественно, пока в реализации «немейнфреймовских» централизованных проектов есть масса технических проблем, но все эти проблемы так или иначе решаются, и вполне явно просматриваются определенные тенденции.
В частности,на вычислительных центрах будущего:
Клиенты будут тонкими, но графическими и с управляемой возможностью подключения к себе устройств хранения информации для ввода и вывода данных из централизованной инфраструктуры.
На центральный узел системы (э... именно на мейнфрейм в первичном значении этого слова) возлагается задача не только хранить данные и забрасывать их на клиенты, но и выполнять львиную долю кодов гостевых систем.
Структура центра будет мультивендорной и мультиплатформенной, потому что никто из производителей не удовлетворяет потребителей в полной мере, и, даже если бы и удовлетворял, то все равно у одного производителя покупать все и всегда никто уже не будет, отвыкли.
Так что мейнфрейм будущего, разработанный для централизованной обработки данных вменяемым производителем, может даже самой IBM, для меня представляется таким, который поддерживает следующие возможности:
Несет на себе аппаратный или полуаппаратный гипервизор для выполнения гостевых ОС различной архитектуры практически без потерь производительности. Это не фантастика, это умеет делать VM за счет специальных команд и управляющий блоков, допуская гостевые машины к "железу” там, где они сами могут обрабатывать прерывания. Осталось распространить данный принцип на другие архитектуры, ведь процессор внутри мейнфрейма давно уже позволяет в зависимости от микрокодов быть каким угодно. Да, проблема непростая, но вполне решаемая.
Обеспечивает подключение устройств всех основных серверных архитектур, благо, их осталось немного и интерфейсов совсем мало, а те, что есть, унифицируются. При этом на Intel-партиции или гостевые виртуальные машины должны проецироваться прелести канальной архитектуры, а именно: работа процессоров ввода-вывода по автономной обработке команд, аппаратно закрепленные приоритеты прерываний ввода-вывода и прочее, хорошо вам известное.
Мейнфейм должен позволять подключать относительно дешевые процессоры гостевых архитектур для получения дополнительной вычислительной мощи. Чтобы при этом не ломалась лицензионная политика, эти дешевые процессорные модули можно было бы задействовать только в предопределенных гостевых системах.
Вот такой мейнфрейм мог бы стать основой облачных центров будущего. Как вам идея? Думаете, маниловщина, да?
Категория: От AKost | Добавил: akost (02.10.2011)
| Автор: Костырко Александр
Я давно бредил чем-то подобным, благо недавно в Win Server 2008 R2 SP1 появилась технология RemoteFX - возможность обрабатывать графику на стороне сервера и пересылать фактически в виде видеоряда на клиент. В принципе, последний барьер перед полнофункциональностью тонких клиентов преодолен. Ставим WinServer 2008, на нем виртуалки с семеркой, подключаемся по RDP 7.1 с клиентов и полнофункциональная рабочая станция готова. Можно хоть в игры играть, хоть в 3DMax работать. Осталось обеспечить каналы связи и распределение нагрузки между нодами сервера. Только вопрос в другом, реализуют ли ( и когда) это счастье на линуксе? Или так и останется виндовой приблудой для x86 архитектуры..
Иван, для меня лично главный вопрос в том, где провести границу между обработкой (в том числе - графики) информации на клиенте и на сервере. Да, на мейнфрейме той архитектуры, что я нарисовал, процессоры расширения задуманы именно для обработки графики и рассчетов, но представляете, какие объемы данных придется прокачивать при вытеснении графики на мейнфрейм? А может, наоборот - пробрасываться будет только экран, и это намного экономнее... В общем, в таком виде было бы круто.
С моей точки зрения все что возможно нужно выделять на сервер, если это возможно технически. Почему? Потому что если что-то оставлять на клиентах, то обязательно придет время модернизации. А модернизация 1000 клиентов зачастую дороже закупки нового, пусть и недешевого сервера. Хотя наверняка бывает и наоборот Деньги-деньги-дребеденьги...
Xwindow существует уже десятки лет, так что и идея и реализация распределенной графики появилась задолго до Win Server 2008) И в OS/2 была реализована распределенная графика насколько мне известно...
VNC и RDP тоже не один год, мы все-таки говорим о терминальных протоколах, которые до сих пор передавали информацию в виде графических примитивов, а отрисовка производилась на клиенте. У Х-сервера, который, строго говоря, удаленкой не является, тоже обрабока происходит на стороне клиента, так что неудачный пример. Полуось щупать не приходилось, тут уж ничего не могу сказать. Сам виндой не пользуюсь, но приходится признать, что это прорыв MS
> Х-сервера, который, строго говоря, удаленкой не является Не могли бы Вы пояснить, что имеется в виду?
Да, X-сервер интерпретирует графические примитивы X-протокола, броузер делает то же самое для HTTP, VNC и др. remote control - для своего протокола, Flash - для своего, RDP для своего, потоковое видео - для своего. Можно еще и GDDM припомнить. Я не понимаю, в чем заключается принципиальная новизна? В степени сложности рендеринга на клиенте?
>Не могли бы Вы пояснить, что имеется в виду? Ну пара Х-сервер Х-клиент предназначена не для удаленного доступа с авторизацией и шифрованием, а для стационарной работы в безопасной среде ( в основном 127.). Отсюда и ее особенности. > Я не понимаю, в чем заключается принципиальная новизна? В степени сложности рендеринга на клиенте? Именно. Точнее в использовании графического оборудования сервера для рендеринга графики. Представьте себе, допустим есть команда из 5 работников в 3D. В чем-неважно. У них есть пять одинаковых машин с мощными видеокартами. Один заболел, один в командировке, двое обедают. Оставшемуся ну никак не доступны свободные ресурсы коллег для сложной работы. (Простите, что рассказываю Вам то, что Вы и сами знаете, но мне непонятен ваш скепсис..)
спасибо за ответ! То, что я считаю, что эта технология не является принципиально новой, ни в коем случае не значит, что я отношусь к ней скептически! IMHO по-настоящему революционных идей и решений в программировании не появилось с 80-ых годов прошлого века...
Идея виртуальных машин различной архитектуры тоже не блещет новизной. Идея-то, конечно, хорошая, и это естественное развитие концепции виртуализации. Но "в одну телегу впрячь не можно коня и трепетную лань". И дело IMHO не столько в различных архитектурах процессора, сколько в различных идеологиях ввода-вывода. Вы и сами здесь говорили о некоторых принципиальных дефектах реализации Linux в MF. Не приведет ли виртуализация архитектуры к подобного рода проблемам?
Лишь бы работало. Мелкие замедления и не оптимальности компенсируется единой элементной базой с разным микрокодом, который проще править. Вот только где поддержка/эмуляция Intel архитектуры на фреймах??
А зачем эмулировать именно Intel? Если не привязываться к винде, то можно избежать кучи проблем. Программы на линуксе компилируются из исходников на чем угодно..
Иван, Интел нужен для массы проприетарных приложений! И для них нет (и не надо!) исходников. Вообще не так много архитектур - i, p, z, x... всего-ничего.
Проблема в позиционировании мейнфрейма в облаке. Для большинства сейчас облака это VMWare. И на вопрос "А как поставить VMWare на железо фрейма" - ответа нет. Даже на вопрос "Как VMWare может взаимодействовать с мейнфреймом" тоже нет ответа. Нарезали под VM тучу z/Linux, а как этим всем управлять едино? Фрейм сам себе облако, VMWare само себе. Текущее VMWare даже Solaris не поддерживает, так что до фрейма руки у них не скоро дойдут.
Ну как показывает опыт с пусть еще пока не очень удобным URM, вполне можно объединить в одной управлялке несколько платформ виртуализации. Вопрос только в командирской воле - сделать все это в рамках одного железа, а не в россыпи ящиков.
я бы так сказал, Григорий. Если система ввода-вывода канальная, то на ней сэмулировать Intel-овский ввод вывод вполне можно. Так что при желании - можно эмулировать интеловскую шины, не роняя соседние виртуальные машины. тут только вопрос командирской технической воли проектировщиков. А вот с Линуксом та же проблема - разработчики Линукса не будут менять ядро, ибо оно единое, а разработчики мейнфрейма не будут ему подыгрывать, ибо оно им нафиг не надо.
Александр, я встречался с ребятами из Крока в начале этого лета ( у них z9 бесхозная на складе валяется). Хотел им предложить совместный бизнес по использованию Z-ки. Крайне удивили Ваши слова про понимание и практическую реализацию идеи централизованных вычислений. Беседа на "высшем уровне" разочаровала меня вконец. Слабое понимание темы (невысокая квалификация), неэффективные решения, "зашоренность", боязнь сделать что-новое - вот такие наблюдения я "подчерпнул" при беседе с ними. Интересно, о чем Вы могли, вообще, с ними договориться?
По мейнферймам в КРОКе нет практически никого, облака, насколько я знаю, разворачиваются через VMWare, так что о мейнфреймах общавшиеся с Вами специалисты могли только слышать. Бесхозная Zка на складе из МГТУ им. Баумана старая, если я не ошибаюсь, и никто с ней не умеет работать. Просто греет склад
Это, Миша, зря. Я ездил в Крок на прошлой неделе. Они потихоньку начинают кое-что понимать, и слова про мейнфреймы нашли понимание. Если сравнить ситуацию сейчас и год назад, то прогресс налицо.
Добавлять комментарии могут только зарегистрированные пользователи. [ Регистрация | Вход ]
Деньги-деньги-дребеденьги...
Текущее VMWare даже Solaris не поддерживает, так что до фрейма руки у них не скоро дойдут.
