IT в России и мире в реалиях мирового кризиса

Цитата: Спокойный от 12.11.2010 03:58:21
Президиум совета при президенте РФ по развитию информационного общества

в целом одобрил идею создания
национальной программной платформы.

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

О, в совете ГА читают  ;):

Цитата: Поверонов от 17.10.2010 14:11:42
Между тем на фоне наших споров о жалком выборе между устаревшим windows и совсем старым linux = unix, поднимается новая  «облачная» волна клиент-серверных систем.  

Придётся обсудить, почему пора проектировать новую ОСь для серверных кластеров.
Как уже упоминалось выше и Unix=Linux и вслед за ними Windows задумывались как многопользовательские=многотерминальные системы. Отсюда - примитивное разделение полномочий между рутом и юзерями, и детский уровень системной безопасности. Конечно в те далекие годы пользователями были лишь научные работники - одуванчики, а единственным хакером в округе был сам рут. О системной безопасности представления были вообще на примитивном уровне разделения доступа к файлам. Все ресурсы - колхозные, сколько кто сможет, столько и возьмет. Позднее кое-что в Линукс донавесили как-то selinux, квотирование дискового пространства, но этого совершенно недостаточно для организации гарантированно безопасных ( друг для друга ) "вечно" ( 24x7 ) работающих сервисов.
Новая ОСь должна обеспечивать не  многотерминальное многопользовательское обслуживание, когда основным источником событий являлся палец на клавиатуре, а набор "вечноживых" многонитевых сервисов. Что это меняет ?
Во-первых, отменяется напрочь такая категория как пользователь. Нечего ему делать на серверах, кроме как коннектиться к сервисам со своего "клиента".
Во-вторых, рут расщепляется по меньшей мере на три категории администраторов:
а) администратор безопасности, который только имеет право определять права всех других администраторов и имеет доступ к соответствующим ключам.
б) системный администратор, который только имеет право распределения общих системных ресурсов между сервисами. ( Каждый сервис обязан довольствоваться отведенной ему квотой памяти, дискового пространства, сетевого траффика и т.д. и т.п.)
в) администратор сервиса, который должен иметь все права на установку и конфигурирование своего сервиса в пределах установленных для сервиса квот.
Причём полномочия между администраторами должны быть разделены так строго, чтобы нижестоящий администратор никоим образом не мог бы влезть в сферу вышестоящего, в то же время имея все возможности выполнения собственных функций в отсутствии других администраторов.

Каждый сервис должен выполнять свои функции, оставаясь строго в рамках своей "песочницы" и никак не залезая на квоты других сервисов. Никаких разделяемых ресурсов, кроме ОС. Единственным способом коммуникации между сервисами должны оставаться "сообщения", транспортируемые друг другу через операционную систему. Никакой общей памяти. Каждый сервис должен функционировать в своей квоте оперативной памяти и уметь "виртуализировать" память самостоятельно через собственный map-файл и/или собственную область подкачки. Очевидно, что ОСь также должна быть способна оставаться в отведенных ей рамках памяти. Только при подобных жёстких ограничениях мыслимо организовать надежную работу серверных кластеров. Понятно, что нынешние ОСи для этого пока слабо годятся.
Чем-то это напоминает уже забываемые ОС реального времени типа RSX. А так же виртуальные машины.
Но это же варварство гонять виртуальные машины только для изоляции сервисов.
Как-то вот так. Пусть IT-общественность добавит, что сможет.

Цитата: Поверонов от 13.11.2010 17:31:07
Но это же варварство гонять виртуальные машины только для изоляции сервисов.

А почему собственно? Виртуализация сейчас вообще аппаратная. Вполне как раз вашу схему можно реализовать в Xen. А XCP так и вовсе для облаков предназначен. OpenVZ опять же посмотрите, там виртуализуется не вся машина.

Ну а так... если остаться в рамках одной операционки, то chroot, acl и сокеты никто не отменял. А квоты... это ерунду вы какую-то говорите... Что по вашему должно делать приложение исчерпавшее свою квоту оперативки? Учтите, приложение памяти не набирает "просто так", если память выделяется, то она приложению нужна для работы (ну в идеале конечно).

Цитата: Поверонов от 13.11.2010 17:31:07
Как-то вот так. Пусть IT-общественность добавит, что сможет.

"Все уже украдено до нас!" (c)

http://ru.wikipedia.org/wiki/Xen
http://ru.wikipedia.…ingularity
http://ru.wikipedia.org/wiki/Erlang

>Отличительной особенностью данной ОС является использование идеологии программно-изолированных процессов (Software Isolated Processes, SIP), похожих на легкие процессы языка Erlang, общение между которыми происходит исключительно посредством сообщений. В отличие от традиционных ОС, защита таких процессов в Singularity производится не путем организации аппаратно-защищенных адресных пространств, а путем использования типобезопасного подмножества промежуточного языка (MSIL) и его верификации перед компиляцией в родной код процессора. Каждый SIP обладает своим объектным пространством, «сборщиком мусора» и средой периода исполнения. Для таких процессов не допускается совместное использование памяти, и они не имеют возможность модифицировать свой код, что усиливает гарантии надежности работы программы в SIP.

В итоге связка вида: железо <-> [ ВМ1 <-> ОС нового поколения (по сути тоже ВМ) ] <-> серверная часть прикладного ПО <- некий протокол -> клиентская часть прикладного ПО на иФоне (или другом потребительском девайсе). Вся серверная часть хостится на облаке, эффективно распараллеливаясь, а клиенту продается подписка. В качестве механизма связи - LTE и др.
Плюс еще важно проработать механизм взаимодействия между таким сервисами(например, чтобы воспользоваться услугами другого сервиса как надежной (No)SQL БД, автоматически разделяя с ним доход от подписки). При наличии развитого рынка системных сервисов и доступных сердств разработки создание сервисов высшего порядка с произвольной масштабируемостью станет вполне посильным делом (фейсбук за два дня: бразуер клиента <-> веб приложение в облаке <-> подписка на БД там же - все за 50 баксов в месяц для начала, а уже если оно выстрелит....). Наиболее перспективные направления: виртуализация (3-4 глобальных игрока), перспективные ОС/рантаймы (1-2 игрока), хозяева облаков (10-15 игроков, с явным отрывом 2-3, которые вряд ли будут делиться своими технологиями) + они же будут поставщиками системных сервисов, разработчики железа (5-6, в 2-3 регионах), разработка инструментария для создания сервисов (по числу ОС + 2-3), глобальные платежные системы (2-4), разработка сервисов и клиентских интерфейсов к ним (много, но за счет глобальности придется жестко конкурировать). Ну и попытки создать себе монополию будут, куда уж без этого.

Добавлю только, что облака скорее всего еще больше повысят степень глобализации и затруднят конкуренцию с лидерами (второй MS не нужен, и второй Google, как это ни странно, тоже, да и ЯблоМагаз №2 вряд ли будет популярен). А один единственный удачный сервис доступен всему миру. Ну и плюс к этому - это уже не вполне будушее... ЯблоМагаз (Андроид Маркет), ГуглДокс(Мап, Мейл, Гаджет, опередивший свое время Вейв), Амазон и пр. пусть пока и на "старых" технологиях (тут вообще революции может и не произойти).

Google Maps практически идеальный пример, учитывая сколько сервисов и ПО на нем основано.

Цитата: bjaka_max от 13.11.2010 20:11:04
Что по вашему должно делать приложение исчерпавшее свою квоту оперативки? Учтите, приложение памяти не набирает "просто так", если память выделяется, то она приложению нужна для работы (ну в идеале конечно).

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

Цитата: mrt789 от 13.11.2010 20:39:12
"Все уже украдено до нас!" (c)

http://ru.wikipedia.org/wiki/Xen
http://ru.wikipedia.…ingularity
http://ru.wikipedia.org/wiki/Erlang

>Отличительной особенностью данной ОС является использование идеологии программно-изолированных процессов (Software Isolated Processes, SIP), похожих на легкие процессы языка Erlang, общение между которыми происходит исключительно посредством сообщений. В отличие от традиционных ОС, защита таких процессов в Singularity производится не путем организации аппаратно-защищенных адресных пространств, а путем использования типобезопасного подмножества промежуточного языка (MSIL) и его верификации перед компиляцией в родной код процессора. Каждый SIP обладает своим объектным пространством, «сборщиком мусора» и средой периода исполнения. Для таких процессов не допускается совместное использование памяти, и они не имеют возможность модифицировать свой код, что усиливает гарантии надежности работы программы в SIP.

Но почему-то MS остановило работу над Singularity.

Цитата
Singularity 1.0 была завершена в 2007 году. Исследовательский пакет Singularity 1.1 Research Development Kit (RDK) был выпущен под лицензией Shared Source и допускает академическое некоммерческое использование; пакет доступен на CodePlex. 14 ноября 2008 г. был выпущен Singularity RDK 2.0. Дальнейшая разработка сосредоточена на инкрементальных релизах.

Может вояки увели разработчиков ?

Цитата: bjaka_max от 13.11.2010 20:11:04
А почему собственно? Виртуализация сейчас вообще аппаратная.

Что Вы конкретно имеете в виду, что виртуализация аппаратная. Кто-то уже загнал гостевую ось в какое-нибудь надцатое ядро ? Или всё-таки гостевые ос по прежнему остаются процессами софтовой виртуальной машины.

Цитата: Valery
Аппаратная реализация виртуализации была реализована в той-же DEC Galaxy с возможностью динамического распределения процессоров по виртуальным машинам. Пока еще дальше никто не продвинулся. (Ну, нравится мнето, что делал покойный DEC)
Кстати, SEVMS была в свое время сертифицирована на В2. Что есть у МелкоМягких? Они и на С2 с трудом смогли (а после и не смогли).

Ну, DEC заслужил, чтобы снять шляпу и почтить его память минутой молчания.
Когда intel ещё в коротких штанишках бегал, DEC уже 64-bit альфу имел на порядки мощнее.
С другой стороны печальная судьба многих IT проектов демонстрирует как чревато почивать на лаврах и презрительно смотреть на мальчишек в коротких штанишках, которые тебя потом и купят, чтобы похоронить как преждевременного гения. Intel перекупил у Compaq Alpha процессор, чтобы просто его забыть.

Цитата: Поверонов от 14.11.2010 01:08:17
Ну, так и должно вытолкнуть все другие сервисы в своп и потом зависнуть в коротком цикле в ожидании  от них ответов  :D. Как это обычно происходит у очень нужных приложений в отношении ненужных, но зачем-то болтающихся на том же сервере.

А в вашем варианте это приложение просто упадёт. И все остальные сервисы от него ответ будут ждать. Даже если в системе дохрена оперативы свободной, которую остальные сервисы не использовали.

Цитата: Поверонов от 14.11.2010 01:57:02
Что Вы конкретно имеете в виду, что виртуализация аппаратная. Кто-то уже загнал гостевую ось в какое-нибудь надцатое ядро ? Или всё-таки гостевые ос по прежнему остаются процессами софтовой виртуальной машины.

Я имею в виду обычный intel vt например. "гостевые" ос управляются гипервизором работающим в root operation режиме. А гипервизор (это вообще не ос в традиционном смысле) только распределяет между ними ресурсы.

Цитата: Поверонов от 14.11.2010 01:57:02
Что Вы конкретно имеете в виду, что виртуализация аппаратная. Кто-то уже загнал гостевую ось в какое-нибудь надцатое ядро ? Или всё-таки гостевые ос по прежнему остаются процессами софтовой виртуальной машины.

VMWare.
http://www.vcritical…ze-itself/

Цитата: bjaka_max от 14.11.2010 08:46:50
А в вашем варианте это приложение просто упадёт. И все остальные сервисы от него ответ будут ждать. Даже если в системе дохрена оперативы свободной, которую остальные сервисы не использовали.

Повторюсь для невнимательных:

Цитата: Поверонов от 13.11.2010 17:31:07
Каждый сервис должен функционировать в своей квоте оперативной памяти и уметь "виртуализировать" память самостоятельно через собственный map-файл и/или собственную область подкачки.

Кстати подобное уже приходило в чьи-то светлые головы:

Цитата: Valery
И ограничение на колличество ожиданий операций ввода-вывода там было реализовано еще в 70-х.
Равно, как и квоты на виртуальное адресное пространство, занимаемое место в своп-файле и т.д.

Цитата: Поверонов от 14.11.2010 15:12:43
Кстати подобное уже приходило в чьи-то светлые головы:

Вообще-то у этого "подобного" даже название своё было: IBM OS/VM.

Цитата: Поверонов от 14.11.2010 15:12:43
Повторюсь для невнимательных:
Кстати подобное уже приходило в чьи-то светлые головы:

Вы лучше объясните зачем это может вдруг понадобиться? И почему этот геморой с отдельным свопом на каждый процесс будет лучше чем сейчас? Между прочим доступ к диску это тоже ресурс. И если приложение (при свободной оперативе, которую другие приложения не использовали) забъёт канал доступа к диску, играя со своим свопом, то вся система встанет колом.

Цитата: bjaka_max от 16.11.2010 15:06:27
Вы лучше объясните зачем это может вдруг понадобиться? И почему этот геморой с отдельным свопом на каждый процесс будет лучше чем сейчас? Между прочим доступ к диску это тоже ресурс. И если приложение (при свободной оперативе, которую другие приложения не использовали) забъёт канал доступа к диску, играя со своим свопом, то вся система встанет колом.

Вы сами назвали Вам ответ : чтобы один неточно сконфигурированный сервис не мог "поставить колом всю систему", перетянув на себя какой-нибудь из ресурсов. Если своп общий, его может до конца "забить" какой-нибудь один жадный процесс. При квотированном свопе такой процесс в худшем случае лишь только сам остановится.
Насчет доступа не думаю, что возможно забить очередь io-операций так,что в нее больше никому не протиснуться. Всё-таки все современные серверы должны иметь внутренний или внешний аппаратный RAID контроллер, который сам организует и кэш блоков обмена и очередь операций.
И вообще трудно представить, как можно перехватить канал доступа, так что в него никто больше не втиснется, всё таки io имеют самые большие таймауты, разве что задать цикл асинхронных io-операций.
Это наверное можно предупредить на уровне ОС, поддерживая круговую дисциплину обращения процессов к каналам io.

Цитата: Поверонов от 16.11.2010 23:40:57
Насчет доступа не думаю, что возможно забить очередь io-операций так,что в нее больше никому не протиснуться. Всё-таки все современные серверы должны иметь аппаратный RAID контроллер, который сам организует и кэш блоков обмена и очередь операций.
И вообще трудно представить, как можно перехватить канал доступа, так что в него никто больше не втиснется, всё таки io имеют самые большие таймауты, разве что задать цикл асинхронных io-операций.
Это наверное можно предупредить на уровне ОС, поддерживая круговую дисциплину обращения процессов к каналам io.

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

Цитата: bjaka_max от 16.11.2010 23:58:52
Ну у нас вот например на ресурсе куча мелких файлов и клиенты постоянно обращаются к разным, при нашей пиковой нагрузке файловая подсистема практически сдыхала, сильно увеличивалось время отклика сервера, резко возрастало количество активных соединений и сервер начинал отрубать входящие. Пока решили установкой твёрдотельных дисков. Возможно придётся кластер организовывать. При том что и процессор и память не кончились. Производительность упёрлась в дисковую подсистему. Ваш подход на нашем сервере, только усугубил бы ситуацию при неблагоприятных обстоятельствах, либо не улучшил бы.

Давайте рассмотрим Вашу ситуацию. Не совсем правда понятно, что здесь можно считать сервисом. Давайте условно считать сервисом каждый процесс, обращающийся к отдельному файлу. Вообще-то Вы описали именно тот случай, который и хочется избежать, когда все сервисы борются друг с другом за общий ресурс, в данном случае - файловую систему.
В обсуждаемом варианте новой ОС каждый сервис имел бы собственный ресурс - отдельную файловую систему- пусть хоть и с одним файлом, и конкуренция на уровне индексов файловой системы была бы развязана. Конечно останется конкуренция на уровне канала ввода-вывода, но она разрешима по круговой очередности: обратился к каналу - получил наименьший приоритет и жди пока он подрастет, чтобы снова схватить канал.
Но организация очередей не может полностью компенсировать недостаточность ресурса - в вашем случае, видимо, слабость дисковой подсистемы. Если у Ваших процессов велика доля операций чтения, то может помочь дополнение оперативной памяти для увеличения буферного пула.  Для этого правда нужно иметь 64-битную ОС. На 32-битной 4G - физический предел. Но если все процессы - пишущие, увеличение буферного пула бесполезно.
Если на сервере есть RAID контроллер, рассмотрите возможность подключения внешнего дискового поля типа IBM EXP3000 с большим числом неёмких дисков. RAID-0 ( striping ) практически увеличивает производительность дисковой системы кратно числу дисков под RAID-0. Если денег хватит, еще лучше ставить RAID-10 ( mirror+striping), тогда и диски легко менять.
Что касается SSD, то производительность MLC сравнима с 15k дисками, но имеет ограничение числа операций записи. При высокой "изменчивости" Ваших файлов SSD MLC могут требовать частой замены.
В этом отношении SSD SLC намного более устойчивы, но жутко дороги пока. Но богатым красиво жить не запретишь

Цитата: Dobryak
…

А несколько лет назад

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

Цитата: Поверонов от 16.11.2010 23:40:57
Вы сами назвали Вам ответ : чтобы один неточно сконфигурированный сервис не мог "поставить колом всю систему", перетянув на себя какой-нибудь из ресурсов. Если своп общий, его может до конца "забить" какой-нибудь один жадный процесс. При квотированном свопе такой процесс в худшем случае лишь только сам остановится.

Ну в VMware примерно так и есть: на каждую ВМ выделяется отдельный своп файл. Правда, в настоящий момент цена даже серверной оперативки позволяет поставить ее достаточное количество, так, что узким местом будет процессор или ОИ (см. ниже).

Цитата
Насчет доступа не думаю, что возможно забить очередь io-операций так,что в нее больше никому не протиснуться. Всё-таки все современные серверы должны иметь внутренний или внешний аппаратный RAID контроллер, который сам организует и кэш блоков обмена и очередь операций.
И вообще трудно представить, как можно перехватить канал доступа, так что в него никто больше не втиснется, всё таки io имеют самые большие таймауты, разве что задать цикл асинхронных io-операций.
Это наверное можно предупредить на уровне ОС, поддерживая круговую дисциплину обращения процессов к каналам io.

Ндаа...

Докладываю: в настоящий момент существует фундаментальная проблема ограничения количества iops на жестких дисках. Самые быстрые 15к дают около 200 iops, 10к - около 150. И если в DL360 я могу спокойно набить 24 гига оперативы (а можно и больше, смысла нет), то поставить больше 8 дисков - не могу. А это - примерно 1500 iops, причем - в теоретическом максимуме, на практике - меньше.

Твердотельные диски, не имеющие таких ограничений, имеют либо космическую цену при мизерных объемах (60-гиговый HP стоит порядка 1200 баксов в онлайн-конфигураторе, ЕМНИП), либо ограниченное число перезаписей у MLC - примерно 3-5 тыс. на ячейку.

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

Цитата: Поверонов от 17.11.2010 01:51:32
Давайте рассмотрим Вашу ситуацию. Не совсем правда понятно, что здесь можно считать сервисом. Давайте условно считать сервисом каждый процесс, обращающийся к отдельному файлу. Вообще-то Вы описали именно тот случай, который и хочется избежать, когда все сервисы борются друг с другом за общий ресурс, в данном случае - файловую систему.
В обсуждаемом варианте новой ОС каждый сервис имел бы собственный ресурс - отдельную файловую систему- пусть хоть и с одним файлом, и конкуренция на уровне индексов файловой системы была бы развязана. Конечно останется конкуренция на уровне канала ввода-вывода, но она разрешима по круговой очередности: обратился к каналу - получил наименьший приоритет и жди пока он подрастет, чтобы снова схватить канал.

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

Цитата: Поверонов от 17.11.2010 01:51:32
Что касается SSD, то производительность MLC сравнима с 15k дисками, но имеет ограничение числа операций записи. При высокой "изменчивости" Ваших файлов SSD MLC могут требовать частой замены.
В этом отношении SSD SLC намного более устойчивы, но жутко дороги пока. Но богатым красиво жить не запретишь

Проблему решило маленькое время доступа твердотельников. Обычные диски кстати сыпались тоже, только держись.

Цитата: bjaka_max от 16.11.2010 23:58:52
Ну у нас вот например на ресурсе куча мелких файлов и клиенты постоянно обращаются к разным, при нашей пиковой нагрузке файловая подсистема практически сдыхала, сильно увеличивалось время отклика сервера, резко возрастало количество активных соединений и сервер начинал отрубать входящие. Пока решили установкой твёрдотельных дисков. Возможно придётся кластер организовывать. При том что и процессор и память не кончились. Производительность упёрлась в дисковую подсистему. Ваш подход на нашем сервере, только усугубил бы ситуацию при неблагоприятных обстоятельствах, либо не улучшил бы.

Ну да. В такой ситуации - или сразу переход к твердотельникам, с их нулевым временем доступа, или городить хитрый огород из маппинга каталогов общего дерева на отдельные физические RAIDы. Чтобы развести обращения к этим маленьким файлам на разные физические диски. В случае борьбы за быстродействие базы данных мы разводили группы таблиц/индексов на отдельные физические диски (использовалось обычное "зеркалирование", а не RAID5, ибо так было эффективнее).