------------------------------ Производитель – IBM
Год выпуска – 2004 год
Дата ввода в эксплуатацию – 2005 г.
Износ: 5 лет эксплуатации
Технические данные
Производительность центральных процессоров 4136 млн. операций в секунду (620 MSU) Количество центральных процессоров 12 шт. Количество процессоров Coupling Facility 2 шт. Объем оперативной памяти 32GB Количество каналов ввода/вывода: FICON 20 шт, ESCON 16 шт, ETHERNET 6 шт.(оптических) и 6 шт.(медных), Coupling Link 6 шт.
Характеристики
Серверы IBM zSeries 990 обеспечивают высокий уровень готовности приложений, необходимый в современной глобальной сетевой среде. Высокая надежность компонентов и особенности конструкции позволяют предотвращать отказы и обеспечивать устойчивость к сбоям. Серверы IBM zSeries 990 имеют архитектуру z/Architecture, которая исключает узкие места, связанные с недостатком адресуемой памяти. Система z990 разработана так, чтобы обеспечивать сбалансированную производительность. Пропускная способность всех устройств — от памяти процессора до системного ввода−вывода и сетевых каналов сбалансированы.
Профилактическое обслуживание:
В течение эксплуатации проводились все плановые профилактические работы и текущие ремонты. Серверы находятся в рабочем состоянии.
Сообщение отредактировал mike - Вт, 30.03.2010, 18:46
Ага, они и Сисплекс-таймеры продают! Интересно, кто их купит, учитывая, что в стране Sysplex только у них и был? Я даже думать боюсь, какой какие там были аргументы по переводу SAP на WIntel, да еще и с Ораклом...
Интересно узнать что они сгородили на WIntel...? Судя по всему у них и pSeries тоже освободились -"Переход на новую платформу потребовал миграции основных прикладных систем SAP R/3, SAP BW, SAP ERP HR с операционных систем zOS, AIX на HP-UX и замену СУБД IBM DB2 на Oracle Database Enterprise Edition" - т.е. меняют зоопарк на НР. ...и специалисты по Z освободились значит...
Ну реальные причины мы, наверное, не узнаем никогда. Но, безусловно, сыграло свою роль желание освободиться от зоопарка техники, а полноценную консолидацию мейнфрейм сделать не позволяет. Я думаю, и нетехнические соображения сыграли свою роль - умение Оракловых специалистов работать с менеджментом очень высокое! Ну и IBM-овцы может быть где-то недоработали. Как раз время пришло технику менять, и консенсуса не состоялось.
Интересно, кто их купит, учитывая, что в стране Sysplex только у них и был?
А вот я никогда особо не понимал. Насколько целесообразно покупать несколько фреймов и не объединять их в сисплекс? Ведь я так понял, что если Сургут был единственным у кого он был, то все остальные владельцы фреймов используют их как отдельные сервера?
А вот я никогда особо не понимал. Насколько целесообразно покупать несколько фреймов и не объединять их в сисплекс?
Ну например, один - основной, на нем идет работа. Второй - резерв, и на нем идет разработка и тестирование. И сисплекса нет, и обе машины задействованы по самые некуда, и резервность соблюдена, ибо в случае сбоя поднять на другом мейнфрейме еще одну виртуалку с системой с другой машины - около 5 минут.
хм, в этой схеме полагается, что оба фрейма имеют доступ на один к одному и тому же стораджу (в смысле банкам данных)?
естественно. и что? на обоих мейнфреймах имеется VM и администратор, который в состоянии написать EXEC в 20 строк для цепляния нужных дисков к виртуальным машинам. альтернативный путь - разделение дисков по LPAR и подбрасывание нужного LPAR на машине, но это уж слишком муторно. а вот с VM - легко, непринужденно и проверено временем.
Sysplex если время простоя критично. Если можно подождать пока инженер допьет кофе и перезапустит - то сисплекс ненужная трата ресурсов. А таймер его еще и денег стоит.
неужто в России нет таких задач с точки зрения ресурсов, которые могут потребовать имплементации сисплекса с целью равномерной распределения нагрузки? мипсов на все задачи хватает?
неужто в России нет таких задач с точки зрения ресурсов, которые могут потребовать имплементации сисплекса с целью равномерной распределения нагрузки? мипсов на все задачи хватает?
А есть приклад способный качественно распределять нагрузку между системами в сисплексе?
На сколько я понимаю, сисплекс позволяет увеличить производительность вычислительной системы для которой наблюдается нехватка ресурсов в выделенном ей LPAR. Любое ПО обеспечивающее одновременный доступ к данным, на том или ином уровне выстраивает очереди к целевым ресурсам. И от того, как эти очереди будут реализованы и зависит максимальная пропускная способность системы, и работает система в сисплексе, или нет, ей для обеспечения целостности данных, этими очередями необходимо оперировать. Настройка системы на очень качественное использование преимуществ сисплекса очень кропотливая и тонкая работа, которая, думаю, в реальном мире встречается очень редко. Как уже отмечалось на форуме, скорее имеет место схема:"Что тут думать 2 LPAR: DB2+WAS и поехали". И вот в таком случае смоделировать нехватку MIPS можно только если поставить себе такую задачу. Не знаю как обстоит дело с этим у CICS, он вроде изначально проектировался как сервер обрабатывающий большое число параллельных транзакций. Под системой понимаю не только ОС, но и ПО крутящееся как на стороне mf так и на стороне серверов приклада/клиентов.
Кстати, а у Сургутнефтегаз был GDPS или просто сисплекс?
Приклад такой есть, называется CICSPlex и IMSPlex, а даже (прости осспади) говорят, что и ADABAS. Что факт - то, что инженеры Software AG каждый раз, как только ИБМ делает какие-то изменения в сисплексе, ещё до анонса прутся в лабу гонять своё чудо, дабы к анонсу уже всё было готово, если потребуются изменения. Да, MQ отлично поддерживает, и способствует распределению нагрузки.
Сообщение отредактировал ggv - Пт, 10.02.2012, 13:36
Приклад такой есть, называется CICSPlex и IMSPlex, а даже (прости осспади) говорят, что и ADABAS.
И назывался он у Software AG - не поверите - ADAPlex!))) А в DB2 - DB2Plex))) Потом Software AG обнаружил, что марка "ADAPlex" уже занята, и свою сисплекс-компоненту назвал ADABAS Cluster Services (тут блабла по этому поводу). На самом деле сисплекс и нужен не только чтобы подбросить систему в случае остановки (я даже на VM делал своими процедурками без всякого сисплекса автоподбрасывание системы на другом VM в случае остановки, без всякого инженера), а для балансирования нагрузки и обеспечения целостности при при перезапусках (для чего и нужен ICF). Вот тут, увы, без сисплекса никак.
Сообщение отредактировал akost - Пт, 10.02.2012, 18:37
