Комментарии 109
восхищаюсь людьми, которые изобрели системы такой сложности и мощи, а ещё восхищаюсь людьми, которые заставляют такие системы работать и понимают, как это всё работает
присоединяюсь!
Насколько все чисто и аккуратно в серверной, что некоторые фото похожи на рендер.
Вы мне льстите. Там было темновато и тесно, так что фотки не очень. :)
..., что совершенно непохоже, что это имеет отношение к РЖД.
Зря вы так. На дороге (ЖД) всегда поддерживалась культура производства. Это мир строгих регламентов, инструкций, журналов исполнения, подтверждений доведения до сведения исполнителей посредством телеграмм и т.д.
Касательно информационной части — поделюсь фото 2007-го года из машзалов ИВЦ МЖД. Это ИВЦ такого же уровня, что и СПб ИВЦ из поста — т.е. ИВЦ уровня дороги (есть ещё ГВЦ РЖД — головной ВЦ на всё РЖД).
Для начала зал с «мелочёвкой» — тут в основном сервера подразделений и всяких сопутствующих подсистем — финансы (АСУ ФР, среди вц-шников более известная как ТДС-4 на базе SAP R/3), кадры (АСУ ТР, тоже сап), сайты, мониторинг и т.д.
А вот здесь крутятся задачи посложнее — АСОУП, Экспресс, т.е. те задачи, которые непосредственно приносят деньги:
А это зал с «историей» — теоретически данное оборудование уже не решает никаких задач, но поддерживается включенным и в работоспособном режиме — на случай необходимости экстренно воспользоваться данными или отказа основной системы:
Касательно информационной части — поделюсь фото 2007-го года из машзалов ИВЦ МЖД. Это ИВЦ такого же уровня, что и СПб ИВЦ из поста — т.е. ИВЦ уровня дороги (есть ещё ГВЦ РЖД — головной ВЦ на всё РЖД).
Для начала зал с «мелочёвкой» — тут в основном сервера подразделений и всяких сопутствующих подсистем — финансы (АСУ ФР, среди вц-шников более известная как ТДС-4 на базе SAP R/3), кадры (АСУ ТР, тоже сап), сайты, мониторинг и т.д.
А вот здесь крутятся задачи посложнее — АСОУП, Экспресс, т.е. те задачи, которые непосредственно приносят деньги:
А это зал с «историей» — теоретически данное оборудование уже не решает никаких задач, но поддерживается включенным и в работоспособном режиме — на случай необходимости экстренно воспользоваться данными или отказа основной системы:
А какое ПО стоит на серверах AIX? Red Hat?
Я не знаю, но можно спросить людей оттуда, они у меня вчера в комментариях появились в блоге.
На третьей фотке детекдет интерфейс IBM Tivoli Business Service Manager.
Там на этой же фотки правда чуть ниже аж целых три монитора с одинаковым зеленым текстом на черном фоне, поэтому, быть может, и остальные «скриншоты» постановочные :)
Там на этой же фотки правда чуть ниже аж целых три монитора с одинаковым зеленым текстом на черном фоне, поэтому, быть может, и остальные «скриншоты» постановочные :)
В репортаже нет ничего постановочного. Меня никто не ждал. Я заходил в комнаты и фотографировал. Так что на экранах что было, то в кадре и оказалось.
Я же написал «быть может». Любопытно, почему там на трех мониторах одно и то же, и какой в этом смысл. Выглядит просто немного подозрительно, вот и всё.
Не знаю. Честно говоря даже внимания не обратил. Можно попробовать спросить у человека оттуда, который здесь в комментариях появился, но что-то он пока не отвечает.
Предполагаю, что эти 3 монитора — от разных рабочих мест, у правого, во всяком случае, стоит кресло, а у левого оно может просто в кадр не влезло. Тогда это может быть дублирование информации для 3 операторов — мало ли, один из них чего-то не увидит или выйдет.
Мне достоверно известно про AIX. IBM же. Но наверняка для разных АСУ может быть целый зоопарк.
Чисто и аккуратно — это радует.
Так это вот здесь все тормозит и глючит иногда при регистрации и покупке билетов?
Если Северо-западное, Уральское или Сибирское направление, то да. :)
А в Екатеринбурге, насколько знаю, РЖД сейчас тоже ЦОД строит.
Так стоит уже.
Что значит строит? Свердловский (отделение ЖД не переименовывалось) ИВЦ существует ой как давно и стоит наравне с Московским и Питерским. Это три ключевых ИВЦ на сети дорог РЖД.
У него помимо меньших пингов есть ещё одно ключевое преимущество для пользователей с Дальнего Востока — сдвинутый часовой пояс, что позволяет сохранить для большинства специалистов и консультантов Московского и Питерского ИВЦ стандартный трудовой день. По сути ночуют лишь диспетчера и дежурная смена.
У него помимо меньших пингов есть ещё одно ключевое преимущество для пользователей с Дальнего Востока — сдвинутый часовой пояс, что позволяет сохранить для большинства специалистов и консультантов Московского и Питерского ИВЦ стандартный трудовой день. По сути ночуют лишь диспетчера и дежурная смена.
Я про тот, который там на Сортировке сейчас строится, вот тут: osm.org/go/2YpUhu4SZ--
Думаю у их проблемы в софте, а не в железе
Возможно. Но если билеты покупаете в пределах Московской ЖД (это не только Москва, по факту почти вся центральная часть России) — то скорее всего всё тормозит и глючит тут:
Вообще почувствуйте разницу, как говорится — эти сервера критичных, но малоприбыльных/убыточных пассажирских перевозок (АСУ Экспресс-3) против красавцев z9 (выкладывал фото в камментах выше) на критичных и весьма прибыльных грузоперевозках (АСУ ГП).
Вообще почувствуйте разницу, как говорится — эти сервера критичных, но малоприбыльных/убыточных пассажирских перевозок (АСУ Экспресс-3) против красавцев z9 (выкладывал фото в камментах выше) на критичных и весьма прибыльных грузоперевозках (АСУ ГП).
Несколько месяцев тут работаю. Если есть какие-то вопросы, спрашивайте. Только, к сожалению, я не смогу ответить на «железные» вопросы, т.к. занимаюсь не этим.
А чем обусловлено такое количество брендов?
Видимо то, что оптимально, то и берут. К тому же это всё не единовременно закупалось.
Под учётные задачи (сап, оракл и прочее) берут SUN-машины. Под крупные производственные АСУ обычно берут IBM.
Всё остальное крутится на x86-мелочёвке, там обычно сервера HP. Ну и почему-то под печать (принтеры, мини-типографии) почти всегда задействуется техника Xerox.
Всё остальное крутится на x86-мелочёвке, там обычно сервера HP. Ну и почему-то под печать (принтеры, мини-типографии) почти всегда задействуется техника Xerox.
Спасибо! Теперь я узнал, что за здание я снимал несколько лет назад! :)
Кликабельно
Хорошее место это, Боровая 53-55…
Славные традиции живут в этих зданиях, всегда в них были серьёзные организации, например «Гипротранссигналсвязь», ВЦ РЖД и держат марку до сих пор.
Славные традиции живут в этих зданиях, всегда в них были серьёзные организации, например «Гипротранссигналсвязь», ВЦ РЖД и держат марку до сих пор.
Мало фоток, мало текста, надо больше золота, во славу Незула.
Пишите ещё!
Что-то теги не отрабатывают. =(
Пишите ещё!
Что-то теги не отрабатывают. =(
Стоит отметить что на Боровой 57 РЖД много площадей сдает в аренду многим провайдерам, так вот в этих помещениях все не так радужно как в зале у РЖД. Вообще Боровая 57 это такой питерский IX.
Меня туда не водили. И у них в той части сейчас ремонт вовсю идёт.
Вообще там дикий совок, олдовые стойки со стеклянными дверьми, все это смонтировано в комнатах с советской отделкой — а-ля старая АТС. На моей памяти там была одна циска, которую собственно оттуда и вывозил при закрытии проекта, так на вопрос о том, что делать с линками и как поаккуратнее забрать кабель питания ( :) ) мне ответили почти «делай что хочешь», на выходе не проверяли вообще что я несу и никто не следил за мной в автозале.
Боровая 57 это такой питерский IX.Это один из питерских IX.
Эта куча разных шкафов напоминает магазин. Каждой модели по 1-2 экземпляра, стоят не вплотную друг к другу, а с зазором, еще и провода спрятали — точно магазин.
Однако, работает.
Судя по тормозящему и глючащему порталу покупки билетов — работает, но не очень…
Понимаете, пассажирка — это отдельная боль для РЖД. Если бы не социальные обязательства — РЖД давно бы от всей пассажирки отказалась, ибо пассажирка жутко убыточна. По ЖД имеет смысл таскать крупнотоннажные грузы — руду, уголь, нефть и т.д. А гонять туда-сюда копеечный по весу пассажирский вагон, но при этом расходовать дорогие нитки графика — получается дорого. Отсюда и отношение к пассажирке — и пристрелить жалко (государство дотирует), и тащить неохота.
А на чём работают сервисы продажи билетов — я выше выложил. И да, там ни разу не x86, проектировалось в 80-90-е, внедрено в 2005-ом.
А на чём работают сервисы продажи билетов — я выше выложил. И да, там ни разу не x86, проектировалось в 80-90-е, внедрено в 2005-ом.
Если не смотреть на стоящую слева открытую стойку вот на этой фотке, то полное ощущение, что попал в какой-нибудь М-Видео в отдел «Холодильники».
Скажите а для каких задач потребовались такие вертикально-масштабированные системы? Я лично никогда не понимал смысла таких дур, может я не понимаю специфики?
Компенсация неоптимизированного прожорливого кода?
Не знаю, к сожалению. Выше в комментариях появился человек оттуда. Можно у него спросить.
О каких именно «дурах» вы говорите?
Да дуры, но есть задачи бизнеса по отказоустойчивости и производительности — вот Вам IBM System Z и VPLEX. Это не дуры, а решения которые призваны решить задачу (извините за каламбур).
Да, но если посчитать стоимость закупки/владения всем этим добром то получится очень даже грустная картина. За эти деньги они бы смогли бы нанять штат разработчиков которые могли бы писать код в течении десятков лет. А далее все это развернуть на горизонтально-масштабируемую архитектуру стоимость которой в сотни раз меньше как в закупке, так и в поддержке, ибо обычно такие системы абгредятся добавляя/удаляя/меняя элементы системы.
Так что повторюсь «Дуры» не от большого ума куплены и меня не переубедить пока не объяснят причину использования подобной системы в данном случае. С другой стороны зачем думать, деньги-то все равно государственные а IBM чай пойди отстегивает за заказы как и всю свою жизнь со своего основания — счетной машинки для переписи населения США / воен заказы / etc.
Так что повторюсь «Дуры» не от большого ума куплены и меня не переубедить пока не объяснят причину использования подобной системы в данном случае. С другой стороны зачем думать, деньги-то все равно государственные а IBM чай пойди отстегивает за заказы как и всю свою жизнь со своего основания — счетной машинки для переписи населения США / воен заказы / etc.
Извините за грубость: НЕТ. Фраза «нанять разрабов… писать код десятки лет», к сожалению, обозначает именно это — писать код десятки лет. По личному опыту чаще всего для бизнеса это значит неудачу. То что вы говорите — снижение CAPEX и увеличение OPEX (капитальные и операционные расходы), но это несёт в себе в данном случае гораздо больше рисков. Система создана, готова и работает. В ней нет необходимости ничего менять. Именно поэтому это решение оправдано.
Жена на днях оптимизировала код москвичей в 1С, операция просчитывалась несколько часов. После примитивного перехода на метод половинного деления проскочила за четверть часа. Москвичи сидят на новой и мощной технике, которая успевает в приемлемое время и без оптимизации, а регионы зачастую на старье, где после нажатия одной кнопки успеваешь сварить и выпить кофе. Когда мне пришлось в своё время работать на 17" трубе с программой типа Scada, сделанной разработчиками под 24" ЖК — проклял всё. Служебные сообщения выскакивали шрифтом на экране меньше миллиметра. Но «эффективные менеджеры» считают, что обновлять парк техники ещё успеется.
Найми изначально грамотных разработчиков, а не блатных — и получишь эффективность, скорость и надёжность.
Разговариваю в оптово-торговой фирме, им требуется админ. Они кочегару в котельную предлагают заметно больше, а тут платить не хотят, да и, собственно, не за что, 15 машинок и файл-сервер. Но ведь им требуется, чтобы за эти копейки я сидел полный рабочий день не выходя из здания. И их не волнует, что в случае сбоя работы кочегара им придётся чуть помёрзнуть, а простой компьютеров сделает работу вообще невозможной.
Ищут постоянного работника третий год…
Найми изначально грамотных разработчиков, а не блатных — и получишь эффективность, скорость и надёжность.
Разговариваю в оптово-торговой фирме, им требуется админ. Они кочегару в котельную предлагают заметно больше, а тут платить не хотят, да и, собственно, не за что, 15 машинок и файл-сервер. Но ведь им требуется, чтобы за эти копейки я сидел полный рабочий день не выходя из здания. И их не волнует, что в случае сбоя работы кочегара им придётся чуть помёрзнуть, а простой компьютеров сделает работу вообще невозможной.
Ищут постоянного работника третий год…
И?
P.S. Разговор выше шёл не о малом бизнесе и кочегарке, а о чуть большем масштабе.
P.S. Разговор выше шёл не о малом бизнесе и кочегарке, а о чуть большем масштабе.
Малый бизнес, в котором пришлось оптимизировать 1С — почта России ;)
У кого больше отделений: у почты или РЖД?
У кого больше отделений: у почты или РЖД?
О, тогда принимаю. Но у Почты России немного другие бизнес задачи, и речь тут не об отделениях — если главный ЦОД Почты России станет на сутки то все посылки и письма придут к получателям, по сути, на сутки позже. Если станет ЦОД РЖД — станут все продажи или будет хаос, так как информация не будет синхронизирована между площадками.
Переписывать софт на горизонтальное масштабирование или еще чего это риск для бизнеса и риск большой, так как гарантий нет, обкатывать это нереально и т.д. Отсюда возвращаемся к выводу о том, что для задач и условий РЖД их существующее решение оправдано и необходимо.
Повторюсь и рафинирую: для каждой задачи есть свои способы её решения. Для этой задачи — этот способ.
Переписывать софт на горизонтальное масштабирование или еще чего это риск для бизнеса и риск большой, так как гарантий нет, обкатывать это нереально и т.д. Отсюда возвращаемся к выводу о том, что для задач и условий РЖД их существующее решение оправдано и необходимо.
Повторюсь и рафинирую: для каждой задачи есть свои способы её решения. Для этой задачи — этот способ.
Хорошо, брошу жену :D
Я почти тридцать лет профессионально занимаюсь энергетикой. С последнего места ушёл по сокращению во время очередной «реорганизации». Мы лет пять пытались объяснить приходящим варягам, что в энергетике главными являются отнюдь не бухгалтеры, а диспетчера. Тем не менее строилась стандартная вертикальная система, создавались довольно примитивные и слабозащищённые по всем параметрам кластеры под бухгалтеров, убиралось резервирование, каналы связи переводились на GPRS и так далее. Лично я устал доказывать, что в случае действительно серьёзной аварии первое, что откажет — это каналы сотовой связи, и мы будем просто вынуждены рассаживать в ключевых точках персонал и посылать курьеров. Устал говорить, что компьютерные системы телеуправления нельзя напрямую подключать к общедоступным сетям. Масштабные аварии в энергетике за последние годы, к примеру май 2005 в Чагино или август 2010 в Питере показали необходимость изменения нынешних подходов… всем, кроме «эффективных менеджеров». Сокращения персонала и рост бумажных мероприятий в ущерб производству продолжаются повсеместно. Уверен, что и в случае с РЖД далеко не всё обстоит именно так, как кажется на первый взгляд.
Я почти тридцать лет профессионально занимаюсь энергетикой. С последнего места ушёл по сокращению во время очередной «реорганизации». Мы лет пять пытались объяснить приходящим варягам, что в энергетике главными являются отнюдь не бухгалтеры, а диспетчера. Тем не менее строилась стандартная вертикальная система, создавались довольно примитивные и слабозащищённые по всем параметрам кластеры под бухгалтеров, убиралось резервирование, каналы связи переводились на GPRS и так далее. Лично я устал доказывать, что в случае действительно серьёзной аварии первое, что откажет — это каналы сотовой связи, и мы будем просто вынуждены рассаживать в ключевых точках персонал и посылать курьеров. Устал говорить, что компьютерные системы телеуправления нельзя напрямую подключать к общедоступным сетям. Масштабные аварии в энергетике за последние годы, к примеру май 2005 в Чагино или август 2010 в Питере показали необходимость изменения нынешних подходов… всем, кроме «эффективных менеджеров». Сокращения персонала и рост бумажных мероприятий в ущерб производству продолжаются повсеместно. Уверен, что и в случае с РЖД далеко не всё обстоит именно так, как кажется на первый взгляд.
Я боюсь что жена по всем параметрам лучше System Z, кроме уж совсем специализированных типа полного дублирования всех составных частей :)
Немного знаком с энергетикой — и там где я сталкивался с энергетикой там были наземные но ужасно медленные каналы. В целом в энергетиках идёт многолетний переход на новую инфру, когда закончат — там посмотрим.
Немного знаком с энергетикой — и там где я сталкивался с энергетикой там были наземные но ужасно медленные каналы. В целом в энергетиках идёт многолетний переход на новую инфру, когда закончат — там посмотрим.
Занимался внедрением. Почти до всех райцентров дотянули каналы по 512 кбит. Процентов 10 самых задвинутых оставалось при мне на 64-128 к. Но многие каналы арендные. Я местные сети в районах раскидывал по копеечной стоимости и, в основном, неофициально. Выбивать с начальства деньги было сложно, проще прятать в счетах на то, что они считают необходимым, свои дополнительные расходы.
ZloyKakPes если честно, я больше согласен с Sava. Всякая вертикальщина возникает не от большого ума и может быть только временным решением. Где-то в параллельной вселенной должен быть штат сотрудников которые должны писать опытный горизонтальный образец. Думаю что с таким штатом у всяких гос структур плохо ибо все нормальные спецы давным давно куплены google, ms, intel на корню с вуза, а остальные разбрелись по хорошему либеральному среднему бизнесу.
ZloyKakPes реально согласись что вполне себе правильный вывод делаю.
ZloyKakPes реально согласись что вполне себе правильный вывод делаю.
ОК, допускаю такое решение. Но я в комментариях выше объяснил почему происходит так как происходит с точки зрения того же бизнеса. Не могли бы Вы объяснить мне, как представителю бизнеса, который считает деньги, почему я должен выкинуть холодильники, и писать код с нуля. И главное — сколько это займёт? Ведь холодильники должны себе еще окупить, а потом устареть. Для commodity это 3-5 лет, а для холодильника примерно вечность, так как обратная совместимость у них вплоть до первого холодильника. В commodity мне этого никто не гарантирует, значит нужна команда поддерживающая и обновляющая код. Правильно? А зачем мне это? Это повышение OPEX, тогда как система стабильна и выполняет свою функцию. И ежегодные на горизонтальное масштабирование OPEX могут, и явно будут, превышать CAPEX на холодильник раз в 10-15 лет.
Давайте говорить в данном случае не как инженеры с точки зрения «красиво» и «не красиво», а с точки зрения бизнеса которому важна «эффективность» и «предсказуемость». Разница в подходах у бизнеса и технарей в учёте понятия «риск» — вторые это понятие часто вообще не учитывают, а «эффективность» для них же понятие эвфемерное, и основанное на личном мнении, а не на реальных числах и данных. Поэтому «должно» и «есть» частенько диаметрально противоположны.
Давайте говорить в данном случае не как инженеры с точки зрения «красиво» и «не красиво», а с точки зрения бизнеса которому важна «эффективность» и «предсказуемость». Разница в подходах у бизнеса и технарей в учёте понятия «риск» — вторые это понятие часто вообще не учитывают, а «эффективность» для них же понятие эвфемерное, и основанное на личном мнении, а не на реальных числах и данных. Поэтому «должно» и «есть» частенько диаметрально противоположны.
В части эффективности вы конечно правы.
Мы правда не знаем всего положения дел и факт коррупции тут практически наверняка, но с точки зрения выполнения задач конечно такое масштабирование является правильным экономическим решением, если масштабирование имеет определенный уровень роста. Однако по поводу экономики я еще раз говорю не факт, в параллельной вселенной обязательно должен существовать другой проект, вторая / третья версия архитектуры и т.д. Тем более при объемах РЖД. Если бизнес растет, то надо выделять ресурсы на улучшения, если бизнес стоит, то надо выделять ресурсы на оптимизацию.
Я все пытаюсь пояснить следующую проблему. У вертикали есть предел мастабирования у горизонтали фактического предела нет и это нам доказывает googe.
В случае с РЖД скорость роста достаточна низкая что бы производить вертикальное масштабирование.
В случае с google/vk такого не достичь в принципе, все упрется в аппаратуру, какой бы сильной она не была и сколько бы терабайт памяти и коилчества ядер не имела.
Мы правда не знаем всего положения дел и факт коррупции тут практически наверняка, но с точки зрения выполнения задач конечно такое масштабирование является правильным экономическим решением, если масштабирование имеет определенный уровень роста. Однако по поводу экономики я еще раз говорю не факт, в параллельной вселенной обязательно должен существовать другой проект, вторая / третья версия архитектуры и т.д. Тем более при объемах РЖД. Если бизнес растет, то надо выделять ресурсы на улучшения, если бизнес стоит, то надо выделять ресурсы на оптимизацию.
Я все пытаюсь пояснить следующую проблему. У вертикали есть предел мастабирования у горизонтали фактического предела нет и это нам доказывает googe.
В случае с РЖД скорость роста достаточна низкая что бы производить вертикальное масштабирование.
В случае с google/vk такого не достичь в принципе, все упрется в аппаратуру, какой бы сильной она не была и сколько бы терабайт памяти и коилчества ядер не имела.
У технарей и бизнесменов разные подходы и оценки, но риски мы учитываем не хуже, чем они. Я твёрдо знаю, что три маленьких гвоздя с постоянным/регулярным контролем состояния всегда надёжнее одного большого.
Заходит вновь назначенный директор по IT компании в мою крохотную серверную сравнительно небольшого подразделения. Да у тебя одно старьё, никакой надёжности, всё выкинуть и серверную упразднить, у нас гигабитный канал и кластер.
Спрашиваю: сколько раз на прошлой недели ваша серверная вставала колом по питанию? И выдёргиваю шнур питания стойки.
— А что у тебя тут?
— Клиент-сервер 1С, файл-сервер предприятия, шлюз на внешнюю сеть, пара серверов телемеханики, сервер записи переговоров, завязана половина области…
— А если сейчас вылетит?
— Я раз в пару месяцев сам проверяю свою систему, текущую нагрузку непосредственно стойка удержит 20 минут, до неё стоят 2х10 кВа бесперебойники диспетчерского оборудования, перед ними стоит и питает помимо этой нагрузки менее ответственные вещи АВР от двух систем шин и резервный дизель. Согласована на всех уровнях нагрузка 25 кВт, пока использую 4.
Хмыкнул, ушёл, через пару недель с барского плеча кинул мне новые стоечные APC и больше не трогал.
Заходит вновь назначенный директор по IT компании в мою крохотную серверную сравнительно небольшого подразделения. Да у тебя одно старьё, никакой надёжности, всё выкинуть и серверную упразднить, у нас гигабитный канал и кластер.
Спрашиваю: сколько раз на прошлой недели ваша серверная вставала колом по питанию? И выдёргиваю шнур питания стойки.
— А что у тебя тут?
— Клиент-сервер 1С, файл-сервер предприятия, шлюз на внешнюю сеть, пара серверов телемеханики, сервер записи переговоров, завязана половина области…
— А если сейчас вылетит?
— Я раз в пару месяцев сам проверяю свою систему, текущую нагрузку непосредственно стойка удержит 20 минут, до неё стоят 2х10 кВа бесперебойники диспетчерского оборудования, перед ними стоит и питает помимо этой нагрузки менее ответственные вещи АВР от двух систем шин и резервный дизель. Согласована на всех уровнях нагрузка 25 кВт, пока использую 4.
Хмыкнул, ушёл, через пару недель с барского плеча кинул мне новые стоечные APC и больше не трогал.
Ну не знаю, я вот не прочь сей час уйти со своей работы, связанной с электронным документооборотом в местный дата-центр РЖД, да вот только без диплома из их ВУЗа практически не реально, а учится в ВУЗе, навыкам которые просто не нужны тоже не интересно.
Проблема в том, что нанять грамотных разработчиков может быть (и, скорее всего, будет) дороже для конечного пользователя.
Да, собственно, исторически сложилось. Вероятно постепенно эта ситуация поменяется, но горизонтальное масштабирование массово стало использоваться относительно недавно — где-то с начала-середины 2000-х, т.е. с развитием широкополосных линий связи.
А разработка промышленных АСУ это дело очень небыстрое — от постановки задачи на проектирование системы профильному НИИ и до момента полноценного внедрения хотя бы на одной сети дорог проходит 10, а то и 15 лет. А ещё были 90-е, которые почти на 10 лет остановили развитие всего и вся.
Вот и получается, что если взять ту же АСУ Экспресс-3, начинали её проектировать в середине 80-х, а вступила в строй (заменила собой Экспресс-2) он только в 2005-ом. И при этом спроектирована под конкретную архитектуру, кросс-платформенной не является. А вы говорите горизонтальное масштабирование — на чём, на модемных линиях в 300 бод? Утрирую, конечно, но всё-таки.
А разработка промышленных АСУ это дело очень небыстрое — от постановки задачи на проектирование системы профильному НИИ и до момента полноценного внедрения хотя бы на одной сети дорог проходит 10, а то и 15 лет. А ещё были 90-е, которые почти на 10 лет остановили развитие всего и вся.
Вот и получается, что если взять ту же АСУ Экспресс-3, начинали её проектировать в середине 80-х, а вступила в строй (заменила собой Экспресс-2) он только в 2005-ом. И при этом спроектирована под конкретную архитектуру, кросс-платформенной не является. А вы говорите горизонтальное масштабирование — на чём, на модемных линиях в 300 бод? Утрирую, конечно, но всё-таки.
На самом деле в ИВЦ не так интересно, как в ЕДЦУ, что на московском вокзале. Именно там октябрьский NOC и центр управления инфраструктурой октябрьской дороги
Очень напоминает «лабы» западных операторов связи. Обычно в «боевых» ЦОДах, все шкафы (cabinets) одинаковые а в лабах разнобой. Хотя справедливости ради скажу что с одним и тем же вендором в Венгрии поставили IBMовские шкафы, а немцы потребовали всё в RITALы переложить. Пришлось писать тест-кейсы на проверку влазят ли блэйд-центры и прочие IBM железо в RITAL. Это при том что до нашего прихода, в Венгерском ЦОДе все шкафы были RITAL и Huawei.
Недостаточно geek porn.
Забавное фото «Работу серверного зала непрерывно контролируют два диспетчера». Один в майке, а второй в кожаной куртке. Т.е. второго или не было и вот только забежал, или вообще посадили левого человека, потому что «должно быть два, а есть один».
Он только что ходил в серверную, стойки молоточком простукивал
Не, постановочных фото тут нет, никого никуда специально не сажали и заранее не предупреждали. Разве что все удивлялись — похоже я их фотографировал на рабочих местах впервые. По поводу куртки не знаю почему так, может человеку нравится в куртке сидеть, а может он только пришёл и не успел раздеться или наоборот уходить собрался.
Вот сотрудников замордовали, чтобы такую чистоту навести…
Вот это я не понял:
Все важные системы дублируются и при сбое нагрузка может быть быстро перенесена на резервные сервера. Команда диспетчеров регулярно тренируется, перенося нагрузку на резервные системы в тестовом режиме.
Разве перенос нагрузки не должен делаться автоматически?
Все важные системы дублируются и при сбое нагрузка может быть быстро перенесена на резервные сервера. Команда диспетчеров регулярно тренируется, перенося нагрузку на резервные системы в тестовом режиме.
Разве перенос нагрузки не должен делаться автоматически?
Вряд ли возможно всё автоматом перенести.
Возможно не всё в процессе переноса можно полностью автоматизировать.
А возможно просто имелось ввиду: «Команда диспетчеров регулярно тренируется, искусственно вызывая процесс переноса нагрузки на резервные системы в тестовом режиме.» просто автор написал вот так, как написал. :) А вот! Автор ответил выше и, судя по всему, первый вариант ближе к истине. :)
А возможно просто имелось ввиду: «Команда диспетчеров регулярно тренируется, искусственно вызывая процесс переноса нагрузки на резервные системы в тестовом режиме.» просто автор написал вот так, как написал. :) А вот! Автор ответил выше и, судя по всему, первый вариант ближе к истине. :)
Перенос нагрузки может произойти со сбоями, именно для этого и нужны диспетчеры.
Скорее всего, у них, как это часто бывает в России, используется модель «Одно приложение — одна стойка». Для IBM P Series используются свои системы хранения, для PureFlex — свои, безумно дорогой EMC VPLEX — еще для чего-то.
Скорее всего, на P-серии IBM у них там Oracle работает какой-нибудь на AIX.
Вот для чего там PureFlex — загадка, конечно. С учетом того, что рядом несколько blade-корзин HP стоит.
Скорее всего, на P-серии IBM у них там Oracle работает какой-нибудь на AIX.
Вот для чего там PureFlex — загадка, конечно. С учетом того, что рядом несколько blade-корзин HP стоит.
Железо крутое да, но что-то вакансии у них там ни о чем.
Люди, которые всё это изобретали, не имеют отношения ни к РЖД, ни к России. Мейнфреймы, сервера, коммутаторы — русского там только импортёр. Ну, ещё монтажник, может быть. Даже оптоволокно — и то не наше.
habr.habrastorage.org/post_images/a22/2a4/500/a222a45000575a65b23db55b229244cb.jpg
В центре HDS USP V
habr.habrastorage.org/post_images/42e/014/532/42e0145327e901a8fd92d600d6f9cd6a.jpg
А тут справа похоже HDS VSP
Обе поддерживают FICON, так что соседство с System Z оправданно.
В центре HDS USP V
habr.habrastorage.org/post_images/42e/014/532/42e0145327e901a8fd92d600d6f9cd6a.jpg
А тут справа похоже HDS VSP
Обе поддерживают FICON, так что соседство с System Z оправданно.
Только сегодня смотрел очередной обзор ДЦ Яндекса. Контраст с этой выставкой холодильников, по-моему, на лицо.
Интересное наблюдение: в последние годы у серверных стоек, которые почти никто никогда не видит, появился дизайн. Теперь многие из них не серые шкафы, а практически произведения искусства.
Как раз наоборот. Раньше SGI этим славилась, а сейчас разве что в корпоративном сегменте такое осталось. Чтобы можно было показать мало чего понимающим в этом боссам, что деньги потрачены не впустую, чтоб те впечатлились бы хоть красивым дизайном.
У SGI рабстанции красивые были, это да. Но вот что действительно было раньше красивым «в большом сегменте» так это мэйнфреймы и суперкомпьютеры.
Вот например Cray-2 с колонной жидкостного охлаждения на инертной жидкости Fluorinnert. Собственно там вся электроника была погружена в эту самую жидкость.
Вот например Cray-2 с колонной жидкостного охлаждения на инертной жидкости Fluorinnert. Собственно там вся электроника была погружена в эту самую жидкость.
На третьей фотке увидел знакомую картинку на втором мониторе с эмулятором терминала IBM3270 Сначала подумал, что в ДЦ стоят AS/400, но потом увидел айбиэмовские мейнфреймы под z/OS и вопрос отпал. Но вот другой вопрос — рабочее место кассира, на четвёртой фотке, оно под какой операционкой? Это не винда, определённо. Такие вещи, обычно, разрабатываются один раз и дальше, в основном, только исправление багов. Прыжки с платформы на платформу(с виндов на линукс,etc) большая редкость. Терминал явно разработан не сегодня и не вчера. В ДЦ явственно чувствуется IBM-овский дух. Так что я яростно надеюсь, что это любимая OS/2. ;)
Но вот другой вопрос — рабочее место кассира, на четвёртой фотке, оно под какой операционкой? Это не винда, определённо.
Судя по
Нагуглилось…
Терминальное оборудование «Экспресс-2А-К»
Часто задаваемые вопросы по терминалу «Экспресс-2АК»
Терминальное оборудование «Экспресс-2А-К»
Часто задаваемые вопросы по терминалу «Экспресс-2АК»
Сколько версий ПО терминала существует в настояший момент?
ПО терминала отличается по типу адаптеров, с которыми оно работает и по типу операционных систем (ОС) под управлением которых оно работает. По типу ОС существует три основных разновидности ПО:
- ПО, написанное как расширение BIOS. Оно вообще не нуждается в ОС, используя прерывания BIOS и непосредственную работу с аппаратурой PC. Это самый первый вариант ПО «Экспресс-2АК» на базе PC. Он был написан В.Г.Афанасьевым.
- ПО, работающее под управление MS-DOS. Это более поздний вариант, написанный С.А.Турсановым. В программу добавлена возможность работы по протоколу гарантированной доставки «Экспресс-3».
- ПО, работающее под управлением Linux. Это последний вариант терминала. Написан С.А.Турсановым и А.П.Поповым. Его можно отличить по графическому интерфейсу. Именно это ПО сейчас устанавливается на терминалы, выпускаемые НПЦ «Спектр».
О как! Как расширение BIOS это сильно! И это ведь до появления всяких там UEFI Спасибо за инфу. Просто в бытность моей работы в ПФР, который тоже активный любитель IBM, так там клиентами к AS-кам были именно машинки под полуосью, до 2004 года. Лепота. Поставил, настроил и забыл. А потом перешли на винду и понеслась.
pure flex красив
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Датацентр РЖД