Случайны выбор дневника Раскрыть/свернуть полный список возможностей


Найдено 1890 сообщений
Cообщения с меткой

эксплуатация - Самое интересное в блогах

Следующие 30  »
Вячеслав_1963

Марксистское эссе

Пятница, 30 Июля 2016 г. 00:18 (ссылка)

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

Есть две разновидности производственных отношений – эксплуатация и коммунизм. Первоначально производственные отношения, ввиду крайне примитивного уровня развития производительных сил, техники производства, – первобытно-коммунистические. С ростом производительности труда, с техническим прогрессом первобытно-коммунистические, неэксплуататорские производственные отношения сменяются эксплуатацией. Эксплуатация возникает вместе с государством и вместе с суеверием. Эксплуатация предполагает существование двух антагонистических классов общества – эксплуатируемых (работников) и эксплуататоров (собственников средств производства). Эксплуататоры присваивают себе плоды труда эксплуатируемых, поскольку в собственности эксплуататоров находятся средства производства. Государство насильственно обеспечивает сохранение собственниками их собственности на средства производства. Соответственно есть три вида эксплуататорского государства – рабовладельческое, крепостническое и капиталистическое.

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

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

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

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

Общественное развитие, наряду с законом соответствия общественных отношений уровню развития производительных сил, подчиняется также и другим законам: переходу количества в качество (рост производительности труда ведёт к революциям в обществе), единству и борьбе противоположностей (эксплуататорский строй есть классовая борьба между эксплуатируемыми и эксплуататорами в рамках единого общества) и отрицанию отрицания (эксплуатация была отрицанием первобытного коммунизма, коммунизм научный будет отрицанием эксплуатации). Революции происходят в результате закономерного созревания революционной ситуации, когда в результате крупных пороков в управлении эксплуататорским государством возрастает страдание эксплуатируемых, которое может перерасти в массовое недовольство эксплуатируемых и в их революционную активность. Революция всегда полезна для общества, поскольку обеспечивает ускорение производительности труда и технического прогресса.

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

О роли DevOps в ИТ — мнения экспертов

Пятница, 22 Июля 2016 г. 19:18 (ссылка)



Изображение сайта tricentis.com



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



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



Оказывается, быстрее могут работать и тестировщики, и менеджеры, и аналитики, и отдел внедрения. Остается всего ничего – придумать, как этого добиться.



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





Изображение сайта quora.com



Модель Agile предусматривает плодотворное взаимодействие отделов разработки и тестирования, осуществляемое в соответствии с общими целями, общими правилами и общими критериями эффективности.

Agile стал достоянием широкой общественности в 2001 году.

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


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



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



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



Выяснилось также, что отдел эксплуатации – это еще одно слабое звено, которое остается «за рамками» модели Agile.







В 2009 создатели DevOps вселили в широкую общественность надежду на светлое будущее.



Вот так формулируются благородные цели DevOps:

DevOps (development и operations) — методология разработки программного обеспечения, нацеленная на активное взаимодействие и интеграцию специалистов по разработке и специалистов по информационно-технологическому обслуживанию. Базируется на идее о тесной взаимозависимости разработки и эксплуатации программного обеспечения, и нацелена на то, чтобы помогать организациям быстрее создавать и обновлять программные продукты и сервисы.


Стоит отметить, что Agile – не является непременным условием для реализации DevOps.



Clyde Logue, основатель StreamStep, говорит об этом так: «Agile сыграл важную роль в разработке для восстановлению доверия у бизнеса, но он нечаянно оставил IT Operations позади. DevOps это способ восстановления доверия ко всей ИТ-организации в целом».



В DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win, описаны лежащие в основе принципы, с помощью которых все DevOps паттерны могут быть получены с помощью подхода «Три пути»:

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



В центре внимания находится все бизнес-потоки по созданию ценности, которые включены в IT.



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



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


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



Мы попросили экспертов ответить на несколько вопросов, чтобы узнать, как обстоят дела с DevOps в русскоговорящем мире.





Евгений Оглоблин, DevOps компании из крупнейшей российской тройки:


1. Каким компаниям подходит DevOps?



Мне кажется, что в достаточной степени любым. Крупным – потому что это позволит ускорить разработку, тестирование и релизы продуктов, маленьким – потому что все будут вовлечены в процесс, появится некоторое подобие взаимозаменяемости сотрудников.



2. Насколько глубоко понимание DevOps в русскоговорящем сообществе?



У нас еще очень много «классических админов», которым про продукт вообще не интересно. У них FreeBSD 8 или CentOS 5, все работает и кушать не просит. Значит, и изобретать ничего не нужно.



Плюс сопутствующая DevOps'у автоматизация подразумевает достаточно много работы, зачастую — с новыми технологиями, иногда вообще не известными людям.



Внятно объяснить, что же такое DevOps, по-моему, до сих пор никто не смог — в любой компании есть свои тонкости, наследие и тому подобное. В общем случае все сходятся на мнении, что это автоматизация, стандартизация и более активное участие отдела эксплуатации в разработке, но этих «всех» не так много, если считать в процентах от общего количества IT-людей.



3. Каковы преимущества DevOps?



В случае успешного внедрения DevOps компании могут в перспективе рассчитывать на:




  • автоматизацию (снижение рисков человеческой ошибки)

  • ускорение и упрощение процессов разработки и релиза

  • получение быстрой обратной связи от пользователей (метрики, мониторинг)

  • PROFIT!!!



4. Каковы недостатки DevOps?



Нужно очень много поработать.



Нужно не забывать про до сих пор актуальные best practices предыдущих поколений – в море новых технологий сделать это легко.



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



DevOps — не серебряная пуля (а жаль).



5. Насколько широко распространился DevOps в СНГ / России?



В компаниях-лидерах IT-рынка — широко распространился. Хотя, как водится, есть исключения. Но живые компании все чаще понимают необходимость современных методологий.





Евгений Потапов, генеральный директор ITSumma:


1 Каким компаниям подходит DevOps?



Существует несколько значений термина, несколько пластов понимания, что же такое DevOps.



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



Если же мы говорим о наборе конкретных практик, связанных с виртуализацией, контейнеризацией, автоматизацией управления инфраструктуры, то здесь самое главное, что компания (а главное сам проект), должна достичь такого размера, при котором накладные расходы на организацию этих практик будут ниже, чем накладные расходы на управление инфраструктурой без них.



2 Насколько глубоко понимание DevOps в русскоговорящем сообществе?



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



3 Каковы преимущества DevOps?



Упрощение коммуникации между специалистами ведет к ускорению взаимодействия.



Пропадает классическая проблема, где программисты винят во всем работу серверов, а администраторы отвечают, что проблемы создает код.



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



Автоматизация же позволяет избавить от извечной рутины и хаоса в ИТ-проектах.



4 Каковы недостатки DevOps?



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



Зачастую накладные расходы на внедрение и поддержку практик автоматизации, таковы, что даже не ускоряют, а замедляют процессы внутри компании.



Да — иметь возможность часто обновлять код проекта — действительно важно, но как часто небольшому проекту надо иметь возможность выкладывать код ежедневно, десятки раз на дню?



При этом человеческие и денежные затраты на поддержание этой возможности довольно велики.



5 Насколько широко распространился DevOps в СНГ / России?



Существуют развитые сообщества DevOps-специалистов, проходят митапы, выходят отличные книги:







Авторы книги DevOps Cookbook и The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win выделяют следующие бизнес-преимущества DevOps:




  • быстрый выход на рынок (сокращение времени цикла и более высокие темпы развертывания);

  • повышение качества (повышение доступности, меньше сбоев и так далее);

  • увеличение организационной эффективности (больше времени тратится на деятельность, связанную с увеличением ценности продукта и количества функционала).



P.S.

Возможно следующим этапом оптимизации командной разработки будет введение телепатической связи между сотрудниками всех отделов и даже с заказчиками.
Original source: habrahabr.ru.

https://habrahabr.ru/post/306260/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

Инструкция по обновлению ПО и первичной настройке Nokia 7750 (SR-7 | SR-12)

Четверг, 21 Июля 2016 г. 17:35 (ссылка)

Данная статья продолжает тему первичной настройки оборудования Nokia (ранее Alcatel-Lucent). Она будет полезна тем, кто не имеет большого опыта эксплуатации данного оборудования, но в ближайшей перспективе планирует связать свои рабочие часы с Nokia 7750 (SR-7 | SR-12)



image



Я постараюсь помочь разобраться в процедуре первичной интеграции 7750 SR на сети, но сразу замечу, что никакая инструкция не сможет заменить официальную документацию от производителя, тем более, что в новых версиях ПО описанные процедуры могут быть изменены. Я планирую ограничиться лишь тем минимумом информации, которая требуется для запуска 7750 и предоставлению к нему удаленного доступа. Тем не менее с готовностью дополню данную статью (либо напишу новую, если вопросы выйдут за ее рамки) информацией, к которой будет проявлен интерес.



Если вас интересует тема первичной настройки Nokia 7210 SAS-M, то ознакомиться с ней можно в соответствующей статье.



1. Обновление ПО на 7750 SR



Первым делом рекомендую обновить ПО (TiMOS) до актуальной версии. Хочу сразу отметить, что в случае использования системы управления 5620SAM, необходимо учитывать, какую максимальную версию TiMOS она поддерживает.



1.1 Подготовка к работе


Что необходимо для проведения работ:



1) Ноутбук с COM-портом или переходник usb-com;

2) Serial кабель. Я использую rollover-кабель Cisco с дополнительным переходником, так как консоль 7750 представляет из себя DB9 разъем (в отличии от 7210, в котором используется RJ45)



image



3) Терминальный клиент (Putty, SecureCRT или аналог);

4) TFTP сервер (tftp32 или аналог);

5) Наличие актуального TiMOS (в качестве примера использовал TiMOS 13.0R10).



1.2 Заливка софта


Для загрузки софта необходимо подключиться к порту Console и настроить параметры сессии следующим образом:



Baud Rate 115,200

Data Bits 8

Parity None

Stop Bits 1

Flow Control None



Прямым кабелем подключаем Management порт 7750 к сетевой карте компьютера. Устанавливаем IP на локальный компьютер (в примере 192.168.1.10/24). Запускаем TFTP сервер и в качестве рабочей папки выбираем каталог с TiMOS.



Если на SR уже установлен TiMOS, то пропускаем пункт 1.3 и переходим сразу к 1.4.



1.3 На оборудовании нет TiMOS (режим monitor)


Нажимаем любую клавишу для начала изменения параметров загрузки. При запросе пароля вводим: “password”. Далее следуем диалогу:



tftp://192.168.1.10/7750/TiMOS-SR-13.0.R10/both.tim #Задаем адрес операционной системы



tftp://192.168.1.10/7750/config.cfg # Задаем адрес конфигурационного файла



Включаем eth-mgmt порт, прописав команду enable и назначаем IP-адрес из той же подсети, что настраивали на компьютере.

При запросе на сохранение конфигурации отвечаем — yes.



После данного шага, операционная система должна загрузиться.



1.4. Оборудование загрузилось (TiMOS)


Логин/пароль: admin/admin



bof # Заходим в меню настройки Boot Options File



no eth-mgmt-disabled # Включаем eth-mgmt



eth-mgmt-address 192.168.1.1/24# Назначаем eth-mgmt адрес нашему 7750



save # Сохраняем Boot Options File



back



file dir #Проверяем свободное место на карте памяти. В случае нехватки памяти файлы можно удалить командой file delete "имя файла"



file md cf1:\TiMOS-13.0.R10 # Создаем папку для нового TiMOS на карте памяти и загружаем в нее системные файлы



file copy tftp://192.168.1.10/both.tim cf3:\TiMOS-13.0.R10\both.tim



file copy tftp://192.168.1.10/both.tim cf3:\TiMOS-13.0.R10\cpm.tim



file copy tftp://192.168.1.10/both.tim cf3:\TiMOS-13.0.R10\iom.tim



file copy tftp://192.168.1.10/both.tim cf3:\TiMOS-13.0.R10\isa-aa.tim



file copy tftp://192.168.1.10/both.tim cf3:\TiMOS-13.0.R10\isa-tms.tim



file copy tftp://192.168.1.10/both.tim cf3:\TiMOS-13.0.R10\support.tim



file copy tftp://192.168.1.10/both.tim cf3:\TiMOS-13.0.R10\boot.ldr



file copy tftp://192.168.1.10/boot.tim cf3:\boot.ldr # Загружаем (перезаписав) boot loader



bof primary-image cf3:\TiMOS-13.0.R10\ # Указываем основной образ TiMOS для загрузки



bof secondary-image cf3:\<Пусть к старому TiMOS, если он есть> # Опционально



bof primary-config cf3:\config.cfg # Указываем файл конфигурации



bof no eth-mgmt-address 192.168.1.1/24 # Удаляем адрес eth-mgmt



bof eth-mgmt-disabled # Отключаем eth-mgmt



bof save



admin save



Файл успешно скопирован, когда оборудование отображает в консоли следующую информацию:



Copying file tftp://192.168.1.10/both.tim ... OK

1 file copied.



После сохранения конфигурации (admin save) необходимо перезагрузить 7750 командой admin reboot upgrade и удостовериться, что оборудование прошло успешную загрузку.



1.5 Резервный процессорный модуль (standby CPM)


Если в 7750 установлен резервный CPM, то необходимо произвести перенос системных файлов и конфигурации на его карту памяти (в системе cf3-b) командой admin redundancy synchronize boot-env



Внимание! С 11-го релиза появился новый файл support.tim. В случае, если обновление производится с версии меньше 11-ой, то данный файл необходимо скопировать на резервный CPM вручную командой copy cf3:\TiMOS-13.0.R10\support.tim cf3-b:\TiMOS-13.0.R10\support.tim



Так же необходимо выполнить команду /configure redundancy synchronize config. Если не применить данную конфигурацию, то при выполнении команды admin save конфигурация не будет сохранена на резервный CPM.



Наличие резервного модуля позволяет выполнить процедуру In-Service Software Upgrade (ISSU). Данная опция не доступна в начальных минорных версиях TiMOS, перед обновлением необходимо ознакомиться с software release notes соответствующей версии ПО.



В данной процедуре присутствуют следующие ключевые команды (считаем, что на момент начала обновления активным является CPM в слоту А):




  1. Копируем софт на cf3 основного CPM в папку cf3:\TiMOS-13.0.R10\

  2. Производим перезапись boot.ldr в корне (cf3:)

  3. Изменяем путь к основному и резервному образу TiMOS в BOF

  4. admin redundancy synchronize boot-env # Cинхронизируем карточки основного и резервного CPM (не забыв про ручное копирование support.tim на старых релизах)

  5. admin reboot standby now # Производим перезагрузку резервного модуля.

  6. show card # Проверяем, что CPM-B перезагрузился и имеет статус up ISSU/standby

  7. admin redundancy force-switchove # Делаем обновленный резервный модуль активным. После этого второй (бывший активный) модуль начнет процесс обновления.

  8. show card# Проверяем, что все карты в состоянии up.



2. Установка и инициализация карт



Линейные карты и MDA необходимо устанавливать в различные части шасси (для SR-7, при наличии двух линейных карт, их следует размещать в 1 и 5 слоты, а не в 4 и 5). Связано это с ограничениям по использованию Timing References. Ref1 может быть использован на карте в 1-2/1-5 слоте, а Ref2 на карте в 3-5/6-10 слоте для SR-7/SR-12 соответственно.



2.1 Определение карт


Установленные в 7750 карты и модули необходимо определять в конфигурации, до тех пор их состояние будет unequipped



configure card <номер слота в шасси>

card-type

mda <позиция mda в карте>

mda-type



Корректным состоянием в выдаче show card и show mda является Admin up, Operational up. Для получения более подробной информации о карте (P/N, S/N, температура и пр.) необходимо добавить в указанные команды detail



2.2 Chassis-mode


Команда configure system chassis-mode <> позволяет настроить набор функций, доступных в шасси. Зависит данный параметр от типа используемых карт:



a (по умолчанию): соответствует набору функций, связанных с iom-20g.

b: соответствует набору функций, связанных с iom-20g-b.

c: соответствует набору функций, связанных с iom2-20g.

d: соответствует набору функций, связанных с iom3-xp



Например, если у вас установлены iom3-xp карты, то необходимо ввести команду configure system chassis-mode d



3. Пример начальной настройки 7750 SR



/configure system name "Имя"



Подготавливаем порт, создаем и ассоциируем с ним интерфейс:



/configure port 1/1/1

description "описание порта"

no shutdown



/configure router

interface "system”

address /32 # Cоздаем системный виртуальный интерфейс

no shutdown

exit



interface "имя интерфейса"

address /30 # IP адрес интерфейса

port 1/1/1 # Порт на нашем оборудовании, с которого уходит линк

no shutdown

exit



/configure router ospf

area 0.0.0.0 # Номер area в которой будет состоять 7750

interface "system" # Обязательно включаем интерфейс "system" в данную арию

exit

interface "имя интерфейса" # Указываем имена всех интерфейсов, входящих в эту арию

interface-type point-to-point # Указываем тип интерфейса

exit



Если 7750 участвует более чем в одной арии, то необходимо прописать вторую арию и все входящие в нее интерфейсы. Если интерфейс участвует так же в non backbone area как secondary, то настраивается он следующим образом:



area 0.0.0.1 interface "system" secondary exit



Данная конфигурация является тем минимумом, который позволит получить удаленный доступ к 7750 SR в сети с настроенным протоколом OSPF.



4. Полезные заметки




  • Просмотреть конфигурацию можно командой «admin display-config». Если необходимо выполнить команду (любую) из места вашего расположения в консоли, то ставим предварительно "/".

  • Выполнив команду «info» можно увидеть конфигурацию, которая относится к ветке вашего расположения. Если необходимо просмотреть так же значения параметров «по умолчанию», то используем «info detail»

  • Командой “show chassis” и “show card” можно узнать температуру шасии и режим работы FAN. Если вентиляторы работают в режиме full speed, то это свидетельствует о повышенном температурном режиме узла.

  • На лицензионной CF карте от Nokia хранится TiMOS и конфигурация, устанавливается она в cf3 процессорной карты. Хорошим решением будет установка дополнительной карты памяти Sandisk (официально поддерживаемый производитель) в слот cf2 или cf1 и использовать ее в качестве хранилища логов.

  • Командой “show chassis” можно получить информацию о питании и его выходе за пределы допустимых значений.

  • Команды “show log log-id 100” и “show log log-id 99” позволят просмотреть Default Serious Errors Log и Default System Log соответственно.

  • Команда «show port» позволит проверить статус портов

  • Команда «show router route-table» отразит таблицу маршрутизации

  • В файле cf3:/bootlog.txt можно найти лог загрузки 7750. Если оборудование не может загрузить TiMOS (например, уходит в циклическую перезагрузку), то информация из данного файла может помочь при проведении диагностики.

  • IOS (Cisco): «ping 1.1.1.1 size 1500 df-bit», в данном случае 1500 байт это размер датаграммы уже с IP и ICMP заголовками.

  • TiMOS (Nokia): «ping 1.1.1.1 size 1472» — 1472 байт говорят о размере поля data в ICMP. Другими словами, добавляем еще 8 байт ICMP и 20 байт IP и получаем те же 1500 байт, что на Cisco.

  • При обращении в техническую поддержку Nokia вам необходимо будет предоставить два tech-support файла, снятые командой "/admin tech-support cf3:<имя файла>.bin" с минимальной временной разницей 15 минут. К сожалению, в отличии от многих других вендоров, данные фалы зашифрованы и прочесть их сможет только инженер Nokia. В случае возникновения каких-либо проблем или аварий, в первую очередь рекомендую снять первый tech-support файл, а дальше приступать к решению проблемы.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306168/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

[Из песочницы] Инструкция по обновлению ПО и первичной настройке Nokia 7210 SAS-M

Среда, 20 Июля 2016 г. 14:20 (ссылка)

Эта статья предназначена для тех, кто хочет разобраться в процедуре первичного введения в эксплуатацию оборудования Nokia (ранее Alcatel-Lucent) 7210 SAS-M. Единственно верный подход при работе с любым оборудованием – предварительное чтение документации. Но реальность такова, что человеку могут поставить задачу срочного запуска оборудования, при этом не подготовив его к грядущей работе. Сроки горят, документации нет, настройка осуществляется “по наитию”. К сожалению, это не редкая жизненная ситуация, но результаты ее, в большинстве случаев, плачевны.





Я постараюсь помочь разобраться в процедуре первичной интеграции 7210 SAS-M на сети, но сразу замечу, что никакая инструкция не сможет заменить официальную документацию от производителя, тем более, что в новых версиях ПО описанные процедуры могут быть изменены. Я планирую ограничиться лишь тем минимумом информации, которая требуется для запуска 7210 и предоставлению к нему удаленного доступа. Тем не менее я с готовностью дополню данную статью (либо напишу новую, если вопросы выйдут за ее рамки) информацией, к которой будет проявлен интерес.



1. Обновление ПО на 7210 SAS-M



Первым делом рекомендую обновить ПО (TiMOS) до актуальной версии. Хочу сразу отметить, что в случае использования системы управления 5620SAM, необходимо учитывать, какую максимальную версию TiMOS она поддерживает.



1.1 Подготовка к работе



Что необходимо для проведения работ:



1) Ноутбук с COM-портом или переходник usb-com;

2) Консольный кабель для 7210. Я использую rollover-кабель Cisco;

3) Терминальный клиент (Putty, SecureCRT или аналог);

4) TFTP сервер (tftp32 или аналог);

5) Наличие актуального TiMOS (в качестве примера использовал TiMOS 7.0R11, но инструкция актуальна для всех версий).



1.2 Заливка софта



Для загрузки софта необходимо подключиться к порту Console и настроить параметры сессии следующим образом:



Baud Rate           115,200
Data Bits 8
Parity None
Stop Bits 1
Flow Control None


Прямым кабелем подключаем Management порт 7210 к сетевой карте компьютера. Устанавливаем IP на локальный компьютер (в примере 192.168.1.10/24). Запускаем TFTP сервер и в качестве рабочей папки выбираем каталог с TiMOS.



Если на SAS-M уже установлен TiMOS, то пропускаем пункт 1.3 и переходим сразу к 1.4.



1.3 На оборудовании нет TiMOS (режим monitor)



Следуем диалогу настройки:



Нажимаем любую клавишу для начала изменения параметров загрузки.



При запросе пароля вводим: “password”



Далее следуем диалогу:



Задаем адрес операционной системы:



tftp://192.168.1.10/7210/TiMOS-7.0.R11/both.tim


Задаем адрес конфигурационного файла:



tftp://192.168.1.10/7210/config.cfg


Включаем eth-mgmt порт, прописав команду enable и назначаем IP-адрес из той же подсети, что настраивали на компьютере.

При запросе на сохранение конфигурации отвечаем — yes.



После данного шага, операционная система должна загрузиться.



1.4. Оборудование загрузилось (TiMOS)



Логин/пароль: admin/admin



Далее выполняем команды:



bof                     # Заходим в меню настройки Boot Options File

no eth-mgmt-disabled # Включаем eth-mgmt

eth-mgmt-address 192.168.1.1/24 # Назначаем eth-mgmt адрес нашему 7210

save # Сохраняем Boot Options File

back

file dir *#Проверяем свободное место на карте памяти. На момент написания инструкции на карту может быть загружено две версии TimOS. В случае нехватки памяти файлы можно удалить командой file delete <имя файла>*

file md cf1:\TiMOS-7.0.R11 # Создаем папку для нового TiMOS на карте памяти

file copy tftp://192.168.1.10/both.tim cf1:\TiMOS-7.0.R11\both.tim # Загружаем образ TiMOS

file copy tftp://192.168.1.10/boot.tim cf1:\TiMOS-7.0.R11\boot.tim # Сохраняем boot loader в папку с соответствующим TiMOS (осуществляется с целью сохранения данного файла для того случая, когда он будет перезаписан более новой версией. Загрузка boot loader осуществляется из cf1:\)

file copy tftp://192.168.1.10/boot.tim cf1:\boot.tim # Загружаем boot loader

*# На вопрос о перезаписи boot.tim отвечаем утвердительно (Yes)*

bof primary-image cf1:\TiMOS-7.0.R11\both.tim #Указываем основной образ TimOS для загрузки

bof secondary-image cf1:\<Пусть к старому TiMOS, если он есть> *# Опционально*

bof primary-config cf1:\config.cfg # Указываем файл конфигурации

bof no eth-mgmt-address 192.168.1.1/24 # Удаляем адрес eth-mgmt

bof eth-mgmt-disabled # Отключаем eth-mgmt

bof save

admin save


После сохранения конфигурации (admin save) необходимо перезагрузить 7210 командой "admin reboot upgrade" и удостовериться, что оборудование прошло успешную загрузку. Хочу обратить внимание, что добавление "upgrade" в команде указывает SAS-M на необходимость обновления CPLD (Complex Programmable Logic Device). Узнать версию CPLD можно командой "show boot-messages". На момент написания инструкции актуальной версией является 2.9



После перезагрузки необходимо завершить процедуру обновлением Golden BOOT Loader командой "admin update-golden-bootstrap"



1.5 Выполняем проверку проведенного обновления



show version – проверка версии TiMOS, на которой работает 7210;

admin check-golden-bootstrap – проверка версии загрузчика;

show boot-messages – проверяем версию CPLD;

file dir – проверка наличия свободного места на карте памяти.



2. Инициализация Media Dependent Adapter (на примере m2-xfp)



На фотографии 7210 SAS-M видно, что в него можно установить опциональный модуль MDA, для работы которого необходимо выполнение ряда процедур.



2.1) Инициализируем карту в bof: use-expansion-card-type m2-xfp



2.2) Исключаем два существующих порта из эксплуатации (например 23 и 24) в bof: no-service-ports 1/1/23 1/1/24

Важно! Конфигурация исключенных портов должна быть полностью очищена:



  port 1/1/23
shutdown
ethernet
exit
exit


В противном случае, после перезагрузки, применение конфигурации на данных портах остановится.



2.3) Инициализируем карту в конфигурации:



  card 1
mda 2
mda-type m2-xfp
sync-e *# Если планируем использовать передачу синхронизации по технологии sync-e*
no shutdown
exit
no shutdown
exit


2.4) Перезагружаем 7210.



2.5) Проверяем корректность определения MDA командой "show mda 1/2 detail"



Примечание: mda 1/1 мы не сможем вытащить, к нему привязаны наши "закрепленные" порты. Но sync-e нужно так же принудительно отражать в конфигурации mda 1/1, если мы хотим использовать данную технологию на портах SAS-M.



3. Пример начальной настройки 7210 SAS-M



/configure system name <Имя>



Подготавливаем порт, создаем и ассоциируем с ним интерфейс:



/configure port 1/1/1
description "<описание порта>"
no shutdown

/configure router
interface "system”
address /32 # Cоздаем системный виртуальный интерфейс
no shutdown
exit

interface "<имя интерфейса>”
address /30 # IP адрес интерфейса
port 1/1/1 # Порт на нашем оборудовании, с которого уходит линк
no shutdown
exit

/configure router ospf
area 0.0.0.0 # Номер area в которой будет состоять 7210
interface "system" # Обязательно включаем интерфейс "system" в данную арию
exit
interface "<имя интерфейса>"* # Указываем имена всех интерфейсов, входящих в эту арию*
interface-type point-to-point *# Указываем тип интерфейса*
exit


Если 7210 участвует более чем в одной арии, то необходимо прописать вторую арию и все входящие в нее интерфейсы. Если интерфейс участвует так же в non backbone area как secondary, то настраивается он следующим образом:



           area 0.0.0.1
interface "system" secondary
exit


Данная конфигурация является тем минимумом, который позволит получить удаленный доступ к 7210 SAS-M в сети с настроенным протоколом OSPF.



4. Полезные заметки




  • Просмотреть конфигурацию можно командой «admin display-config». Если необходимо выполнить команду (любую) из места вашего расположения в консоли, то ставим предварительно "/".

  • Выполнив команду «info» можно увидеть конфигурацию, которая относится к ветке вашего расположения. Если необходимо просмотреть так же значения параметров «по умолчанию», то используем «info detail»

  • Командой “show chassis” и “show card” можно узнать температуру шасии и режим работы FAN. Если вентиляторы работают в режиме full speed, то это свидетельствует о повышенном температурном режиме узла.

  • Требования Nokia к температурному режиму сайта:

    — Для 7210 SAS-M необходимо организовать поддержание температуры на сайте в диапазоне от 0 до 50 °C.

    — Для 7210 SAS-М 24F 2XFP ETR необходимо поддерживать температуру на сайте в пределах от -40 до 65 °C.

  • Командой “show chassis” можно получить информацию о питании и его выходе за пределы допустимых значений.

  • Команды “show log log-id 100” и “show log log-id 99” позволят просмотреть Default Serious Errors Log и Default System Log соответственно.

  • Команда «show port» позволит проверить статус портов

  • Команда «show router route-table» отразит таблицу маршрутизации

  • Если вам досталась призовая игра, а точнее 7210 SAS-M с TiMOS 2-ой версией и ниже, то обновление выполняется через 3-ий релиз. Так же отмечу, что через MGM порт софт не зальется, для этой задачи необходимо использовать порты 1/1/1 или 1/1/2.

  • IOS (Cisco): «ping 1.1.1.1 size 1500 df-bit», в данном случае 1500 байт это размер датаграммы уже с IP и ICMP заголовками.

  • TiMOS (Nokia): «ping 1.1.1.1 size 1472» — 1472 байт говорят о размере поля data в ICMP. Другими словами, добавляем еще 8 байт ICMP и 20 байт IP и получаем те же 1500 байт, что на Cisco.

  • При обращении в техническую поддержку Nokia вам необходимо будет предоставить два tech-support файла, снятые командой "/admin tech-support cf1:<имя файла>.bin" с минимальной временной разницей 15 минут. К сожалению, в отличии от многих других вендоров, данные фалы зашифрованы и прочесть их сможет только инженер Nokia. В случае возникновения каких-либо проблем или аварий, в первую очередь рекомендую снять первый tech-support файл, а дальше приступать к решению проблемы.


Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/306030/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

К вопросу реализации персистентных процессов в управляющих системах реального времени (часть 3)

Четверг, 23 Июня 2016 г. 22:05 (ссылка)

Перейти к части 1

Перейти к части 2



4. Системные сервисы и операционные среды



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







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



Может показаться естественным шагом установить внутри виртуальной машины ту же самую версию Linux, что и на поддерживающей её хост-системе (то есть, например, SLES или RHEL). Это имеет те преимущества, что требует учёта особенностей и поддержания политики обновления только одного продукта, а также позволяет использовать общую лицензию для физического сервера и его виртуальных машин. Однако, данный подход имеет и существенный недостаток, связанный с тем, что SLES и RHEL – это дистрибутивы, гораздо более ориентированные на администратора, управляющего стандартными приложениями, нежели на разработчика, и поддержка на них окружения для выполнения программ, полученных в последних версиях средств разработки, может потребовать существенной дополнительной работы по управлению конфигурацией системных и внешних пакетов.



Поэтому, с нашей точки зрения, не имеет особого смысла гнаться за единством операционной среды между хостом и виртуальной машины, и в качестве ОС ВМ гораздо удобнее использовать тот дистрибутив Linux, к разработке под который вы привыкли.



Примечание для госсектора
Неплохие результаты может показать применение в качестве ОС ВМ отечественного дистрибутива операционной системы Astra Linux. Этот дистрибутив свободно распространяется в “гражданской” версии Common Edition и недорог в “военной” версии Special Edition, достаточно оперативно обновляется разработчиками, удовлетворяет многим специальным требованиям государственных органов и полностью укладывается в политику импортозамещения. Таким образом, использование Astra Linux на виртуальной машине позволяет получить определённые конкурентные преимущества на российском рынке, хотя мы и не можем, по целому ряду причин, порекомендовать эту систему для работы непосредственно на физических серверах среднего и высшего уровня.




Разумеется, ОС ВМ не менее, чем ОС физической машины, потенциально способна к сбоям и отказам. Задача избыточности вычислительной платформы, на физическом уровне решаемая кластеризацией, на виртуальном уровне решается реализацией фунций системы на нескольких взаимосвязанных виртуальных машинах, контролирующих работу друг друга. Задачу контроля работоспособности, на физическом уровне решаемую строжевыми таймерами, можно было бы на виртуальном уровне решать так же – виртуальным устройством сторожевого таймера — но гораздо проще и функциональнее осуществлять из контролирующей виртуальной машины выдачу команд кластеру на перезапуск контролируемой виртуальной машины (разумеется, контроль должен быть перекрёстным). Образы виртуальных машин легко сохранять для создания точек отката и аварийного восстановления.



5. Вычислительные процессы



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



Итак, реализуя меры, описанные выше в статье, нам удалось обеспечить свойство персистентности на уровнях внешних ресурсов, среды связи с ними, аппаратуры и встроенных программ, хостовой операционной системы, системных сервисов и операционных сред. Дело за малым – обеспечить, чтобы сами наши процессы выполнялись стабильно в обеспеченной им стабильной вычислительной среде.



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



Многочисленные средства обеспечения отказоустойчивости, описанные выше, обеспечивают восстановление готовности вычислительной среды, но в некоторых случаях могут приводить к перезапускам отдельных вычислительных процессов. В этих условиях первостепенно важной является устойчивость этих процессов к перезапускам самих себя и своих соседей, с которыми происходит взаимодействие. Такая устойчивость может быть реализована через отсутствие макросостояния вычислительного процесса. Как уже упоминалось в разделе 2, крайне нежелательно установление длительных соединений между процессами, которые в любой момент могут быть прерваны отработкой нештатной ситуации на одном из концов. Обмен управляющими сигналами между процессами должен быть сведён к коротким транзакциям, для каждой из которых должна быть предусмотрена возможность неуспеха и повторения или парирования в этом случае. В простейшем случае, такие транзакции сводятся к посылке единичных пакетов. Кроме того, каждый процесс должен периодически сохранять в энергонезависимой памяти (т.е., в нашем случае, на виртуальном диске) информацию, достаточную для восстановления своей работы с наиболее практически применимой контрольной точки в случае собственного перезапуска.



Особое внимание необходимо уделить взаимодействию процессов с СУБД. Если СУБД применяется в проекте, то необходимо реализовать как осмысленную транзакционную структуру самой схемы данных, так и транзакционный характер сетевых соединений клиентов с сервером СУБД. Связь клиента и сервера должна иметь возможность восстанавливаться при нештатном перезапуске того и другого, чего проще всего достичь, укорачивая транзакции и оборачивая каждую транзакцию в отдельное сетевое соединение, в течение короткого промежутка времени инициируемое, выполняемое и разрываемое.



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



while [1]

do

my_executable_module

done





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



В заключение хочется заметить, что даже аккуратнейшая и безошибочная реализация каждого из рассмотренных уровней не гарантирует разработчика от неприятностей, связанных с неучтённым взаимодействием между ними. Поэтому доведение отказоустойчивой системы до требуемых показателей надёжности может занимать значительное время и требует полного тестирования функций всех уровней системы на отработку отказов на каждом из них.
Original source: habrahabr.ru (comments, light).

https://habrahabr.ru/post/303974/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

К вопросу реализации персистентных процессов в управляющих системах реального времени (часть 2)

Вторник, 14 Июня 2016 г. 22:12 (ссылка)

Продолжение статьи.



Начало: часть 1



3. Аппаратура и встроенные программы



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



Прежде всего, по нашему глубокому убеждению, никакая серьёзная статья об отказоустойчивости немыслима без отдачи дани уважения фирме IBM и платформам z Systems и Power Systems. Мейнфреймы z Systems и кластеры Power Systems HA специально спроектированы таким образом, чтобы обеспечить на аппаратном, микропрограммном и системном программном уровне единую отказоустойчивую платформу для приложений пользователя, и по надёжности потенциально превосходят те решения, которые можно реализовать на более распространённой архитектуре Intel. К сожалению, упомянутые решения IBM имеют также определённые недостатки, наиболее общим из которых является их стоимость. Опыт разработчиков показывает, что, при современной стоимости z, p и Intel-решений (самого железа и лицензионных программ для него), а таже при теперешнем курсе доллара к рублю, достаточно сложно в российских условиях экономически оправдать новые вложения в проприетарные архитектуры, даже с учётом значительных дополнительных трудозатрат на обеспечение заданных показателей надёжности у решений Intel. В общем, коллеги, работающие с “большим железом” сами хорошо знают свои резоны, их путь весьма уважаем, но не может быть рекомендован новичку.



Примечание для госсектора
Здесь мы вынуждены сделать развилку в логике нашего изложения, и учесть тот факт, что значительная доля рынка отказоустойчивых систем в России ориентирована на потребности государственного сектора. Поэтому для разработчиков, обременённых, кроме прочих забот, почётными обязанностями по обслуживанию пожеланий государства, заметим следующее. В настоящее время, как известно, Правительством РФ провозглашена политика импортозамещения. В своей наиболее принципиальной форме эта политика подразумевает исключительное использование продукции производства России и стран ЕАЭС. Однако, ряд руководящих документов устанавливает более мягкие требования, диктующие ограничение использования продукции только стран НАТО, Европейского Союза и других, поддерживающих режим секторальных санкций в отношении РФ. Для сферы информационных технологий существенно, что под режим таких мягких ограничений не подпадают КНР (включая Тайвань) и Япония, что выводит в первые ряды для рассмотрения серверные системы компаний Lenovo (весьма удачно перекупившей к выходу соответствующего постановления Intel-совместимый бизнес IBM) и Fujitsu.




Рассматривая Intel-совместимые решения в области отказоустойчивых аппаратных средств, следует обратить внимание, в частности, на следующие моменты:

– горячее резервирование серверов;

– горячее резервирование сетевого оборудования и соединений между серверами;

– горячее резервирование дисковой памяти в системе хранения данных;

– устойчивость встроенного программного обеспечения к сбоям;

– контроль рабочего состояния ОС.



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



Устойчивость встроенного программного обеспечения к сбоям обеспечивается специальными алгоритмами прошивки UEFI и сервисных контроллеров на серверных платформах. Например, для серверов могут обеспечиваться автоматическое резервирование и восстановление прошивок аппаратуры, автоматическое резервирование загрузчика операционной системы и т.п.



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



Однажды автору довелось наблюдать поведение блейд-сервера фирмы Lenovo, при обновлении загрузчика операционной системы на котором произошёл сбой, и файлы конфигурации загрузчика записались с ошибкой. Загрузчик начинал грузить ядро Linux, после чего зависал. Через некоторое время в сервисном процессоре сервера срабатывал таймаут загрузки ОС, и сервер перезагружался. Прошивка UEFI сервера, обнаружив, что предыдущая попытка загрузки завершилась неуспехом, самостоятельно принимала решение об откате к предыдущей версии загрузчика из архивного каталога, вызывала его, и система благополучно загружалась. Так система, которая на обычной платформе уровня рабочей станции была бы неоперабельной до ручной загрузки с ремонтного раздела, на серверной платформе благополучно автоматически загружалась в два приёма, до тех пор, пока следующим обновлением не был восстановлен правильный загрузчик. От администратора при первоначальной настройке системы требовалось только выставить корректное значение таймера загрузки.



К широко известным средствам обеспечения отказоустойчивости серверов относятся память ЕСС, объединение дисковых носителей в избыточные RAID массивы, дублирование всех компонентов серверов и серверных шасси, обеспечение альтернативных путей связи между компонентами серверной системы и пр.



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



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



4. Хостовая операционная система



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

– поддержка физического оборудования;

– поддержка среды виртуализации и кластеризации;

– стоимость;

– требования по сертификации и защищённости.



Отказоустойчивые серверные платформы заявляются производителем как совместимые только с небольшим количеством операционных систем. В типичном случае, к таким системам для Intel-совместимых платформ относятся Windows, Red Hat Enterprise Linux (RHEL), Suse Linux Enterprise Server (SLES) и VMware vSphere. Установка других операционных систем возможна, но, как правило, приводит к отсутствию штатной поддержки критичных для обеспечения отказоустойчивости аппаратных возможностей (например, средств multipath для резервирования дисковых контроллеров).



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



Основными используемыми на сегодняшний день средствами серверной виртуализации для Unix-совместимых систем являются VMware ESXi, KVM (Red Hat и SLES), Xen (SLES). Все эти платформы обеспечивают кластеризацию виртуальных машин (в качестве дополнительной опции), то есть поддержку автоматической миграции виртуальных машин с вышедшего из строя узла на резервный.



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



KVM и Xen представляют собой решения попроще и подешевле. К достоинствам KVM относится бо

https://habrahabr.ru/post/303296/

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
rss_rss_hh_new

К вопросу реализации персистентных процессов в управляющих системах реального времени (часть 1)

Понедельник, 13 Июня 2016 г. 15:45 (ссылка)

В последнее время очередным модным термином в информационных технологиях стала “персистентность”. Много статей публикуется о персистентных данных, dzavalishin разрабатывает целую персистентную операционную систему, поделимся и мы для разнообразия материалами недавно сделанного доклада о персистентных процессах.



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



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



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



Например, таким:














Вычислительные процессы
Специализированная резервированная аппаратура
Среда связи с ресурсами
Внешние ресурсы


таким:




















Вычислительные процессы
Кластеризованные системные сервисы и операционные среды
Хостовая операционная система
Аппаратура и встроенные программы
Среда связи с ресурсами
Внешние ресурсы


или, теоретически, даже таким:




















Вычислительные процессы
Кластеризованный сервер приложений
Системные сервисы и операционная система
Аппаратура и встроенные программы
Среда связи с ресурсами
Внешние ресурсы


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



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



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



1. Внешние ресурсы



Иногда начинающие разработчики упускают из виду, что, зачастую, наиболее уязвимым звеном контура управления могут являться сами управляемые ресурсы или другие внешние объекты. Эта ситуация прекрасно иллюстрируется старым анекдотом:



– Я – самая умная! – сказала Википедия.

– Я найду что угодно! – сказал «Гугл».

– Я – всё! – сказал Интернет!..

– Ну-ну – сказало Электричество и… моргнуло.




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



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



2. Среда связи с ресурсами



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



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



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



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



Двигаясь выше по стеку протоколов, необходимо затронуть вопрос использования устойчивых к полным или частичным сбоям протоколов передачи данных. Частью этого вопроса является широко известный флейм TCP vs UDP.



К достоинствам использования протокола TCP в управляющих системах относятся:

– автоматический контроль целостности;

– произвольный размер передаваемых данных.



К достоинствам использования протокола UDP в управляющих системах относятся:

– отсутствие состояния;

– возможность полудуплекса;

– быстрый возврат из вызовов*;

– быстрая диагностика проблем на уровне стека и возврат кода ошибки.



Использование TCP в системах реального времени требует от разработчика знакомства с параметрами настройки стека, в первую очередь семейством параметров tcp_keepalive. Использование UDP требует чёткого понимания реализации протокола ARP (с этим связана оговорка для сноски* выше). Использование обоих протоколов подразумевает творческое владение настройками размера приёмного буфера.



Вопрос отсутствия состояния у протокола UDP приобретает важность при перезапуске одной из сторон соединения, в том числе – перезапуске на физически отличающемся оборудовании (резервном сервере).



Отдельно необходимо затронуть редко освещаемый вопрос полудуплекса. Реализация некоторых распространённых сетевых сред такова, что, в результате физического или логического нарушения целостности связи, становится возможной ситуация, когда данные передаются от A к Б, но не могут быть переданы от Б к А. Протокол TCP не может функционировать в таких условиях. Протокол UDP способен сохранить одностороннюю связь при одностороннем обрыве (при условии корректной работы нижележащего сетевого оборудования, и исключая вопросы использования ARP при установлении соединения).



В целом, по мнению автора, для передачи коротких управляющих сообщений в IP сети для отказоустойчивой системы более подходит протокол UDP с организацией контроля доставки сообщений или безусловной повторной рассылки на уровне прикладных программ. Для передачи больших объёмов данных подходит координируемое управляющим уровнем использование протокола TCP, с организацией соединений на короткое время.



Продолжение следует.
Original source: habrahabr.ru.

https://habrahabr.ru/post/303162/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
Razgulyaev

Управление территориями

Четверг, 19 Мая 2016 г. 09:08 (ссылка)

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

ЗАКАЗАТЬ КНИГУ можно здесь -
http://restavrika.ru/продукты/эксплуатация-территории/
Эксплуатация территории обложка (448x640, 156Kb)

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
SoftLabirint

Библиотека домашнего мастера, ремонта, инженера, самоделкина - Сборник 95 книг (2002-2014) PDF, DJVU, FB2, EPUB, DOC » SoftLabirint.Ru: Скачать бесплатно и без регистрации - Самые Популярные Новости Интернета

Вторник, 26 Апреля 2016 г. 18:27 (ссылка)
softlabirint.ru/book/23476-...b-doc.html


Библиотека домашнего мастера, ремонта, инженера, самоделкина - Сборник 95 книг (2002-2014) PDF, DJVU, FB2, EPUB, DOC

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



Список библиотек:



1. Библиотека инженера. 22 книги (2002-2009) PDF,DJVU



1. А.Г.Булгаков, В.А.Воробьев Промышленные роботы. Кинематика, динамика, контроль и управление, 2007, djvu

2. Афонский А.А., Дьяконов В.П. Измерительные приборы и массовые электронные измерения, 2007, pdf

3. Афонский А.А., Дьяконов В.П. Цифровые анализаторы спектра, сигналов и логики, 2009, pdf

4. Васильченко Е.В., Наседкин К.С. Проектирование схем на компьютере, 2004, djvu

5. Виноградов Ю.А. Охранная техника, 2008, djvu

6. Гейтенко Е.Н. Источники вторичного электропитания схемотехника и расчет, 2008, pdf

7. Дингес С.И. Мобильная связь технология DECT, 2003, djvu

8. Дьяконов В.П. Энциклопедия устройств на полевых транзисторах, 2002, djvu

9. Жаднов В.В., Сарафанов А.В. Управление качеством при проектировании теплонагревателей радиоэлектронных средств, 2004, djvu

10. Карлащук В.И., Карлащук С.В. Электронная лаборатория на IBM PC, 2008, djvu

11. Карлащук В.И., Карлащук С.В. Спутниковая навигация. Методы и средства, 2006, pdf

12. Литюк В.И., Литюк Л.В. Методы цифровой многопроцессорной обработки ансамблей радиосигналов, 2007, djvu

13. Николайчук О.И. Системы малой автоматизации, 2003, pdf

14. Петров И.В. Программируемые контроллеры, 2004, djvu

15. Самарин А.В. Жидкокристаллические дисплеи, 2002, djvu

16. Семенов Б.Ю. Микроконтроллеры MSP430. Первое знакомство, 2006, djvu

17. Степанов А.В., Матвеев С.А. Метод компьютерной обработки сигналов систем радиосвязи, 2003, pdf

18. Титов А.А. Транзисторные усилители мощности МВ и ДМВ, 2006, djvu

19. Фельдман Я.А. Создаём информационные системы, 2006, pdf

20. Хныков А.В. Теория и расчет трансформаторов источников вторичного электропитания, 2004, djvu

21. Семенов Б.Ю. Силовая электроника. От простого к сложному, 2005, djvu

22. Голубцов М.С. Микроконтроллеры AVR. От простого к сложному, 2003, djvu



2. Библиотека домашнего мастера. 19 книг (2012-2016) FB2,PDF,EPUB



Бассейны, пруды и фонтаны. Строительство, эксплуатация, ремонт

Внутренняя отделка. Современные материалы и технологии

Водоснабжение загородного дома. Трубные и буровые колодцы, скважины

Гардеробные и шкафы-купе. Оригинальные идеи и новейшие материалы

Канализация загородного дома. Строительство. Эксплуатация. Ремонт

Монтаж и эксплуатация электропроводки. Выключатели, розетки, щитки, светильники

Отделка, эксплуатация, ремонт печей и каминов. Материалы, технология работ

Отопительные печи для загородных домов. Эксплуатация

Современная крыша и кровля. Оригинальные идеи, новейшие материалы и технологии работ

Современные балконы и лоджии. Оригинальные идеи, новейшие материалы и технологии работ

Современные двери и окна. Новейшие материалы и технологии работ

Современные мансарды, крыльца, террасы, беседки и зимние сады. Оригинальные идеи, новейшие проекты, технологии работ

Современные отделочные материалы. Виды, свойства, применение

Современные погреба, гаражи, летние кухни и летний душ. Оригинальные идеи, новые проекты

Современные полы. Технологии и материалы

Современные работы по закладке фундамента. Виды работ, материалы, технологии

Современный ремонт дома и квартиры. Новые материалы и технологии работ

Стеллажи и полки своими руками. Материалы и технологии изготовления

Установка сантехники в загородном доме, квартире гидромассажные ванны, унитазы, раковины, умывальники



3. Библиотека самоделкина. 43 книги (2014) PDF,DJVU



100.работ.для.умелых.рук.djvu

100.резных.рам.и.рамок.своими.руками.djvu

200.работ.для.умелых.рук.djvu

700.практических.советов.djvu

1000.мелочей.из.кожи.djvu

1000.полезных.советов.djvu

1000.советов.любителю.мастерить.djvu

1000.советов.мастеру.на.все.руки.djvu

2000.сoвeтoв.для.нeумeлых.pук.djvu

Выпиливание.лобзиком.djvu

Домашние.коптильни.pdf

Домашние.тапочки.своими.руками.djvu

Домашний.слесарь.djvu

Домашняя.мастерская.djvu

Индивидуальная.электростанция.djvu

Книга.домашнего.мастера.djvu

Кресло-качалка.djvu

Малая.механизация.в.приусадебном.хозяйстве.pdf

Маленькие.хитрости.для.домашнего.мастера.djvu

Маленькие.хитрости.домашнему.мастеру.djvu

Мастерская.djvu

Мастеру.на.все.руки.djvu

Мебель.своими.руками.1.djvu

Мебель.своими.руками.2.djvu

Отремонтируй.стиральную.машину.djvu

Очумелые.ручки.djvu

Плетение.1.pdf

Плетение.2.pdf

Плетение.из.ивового.прута.pdf

Плетение.из.соломы.pdf

Поделки.из.веток.djvu

Полезные.советы.любителям.мастерить.djvu

Ремонт.одежды.и.обуви.в.домашних.условиях.djvu

Ремонт.часов.своими.руками.djvu

Самоделкин.djvu

Самоучитель.по.ремонту.ванн.djvu

Светодиодная.лампа.своими.руками.djvu

Сделаем.сами.для.дома.и.дачи.djvu

Сделай.сам.1.djvu

Сделай.сам.2.djvu

Справочник.домашнего.мастера.djvu

Чудесная.проволока.djvu

Это.вы.можете.djvu



4. Библиотека ремонта. 11 книг (2002-2005) PDF,DJVU,DOC



Иванов И. Регистрация трубок радиотелефонов

Корякин-Черняк С.Л. Автосигнализации от А до Z. 3-е издание

Корякин-Черняк С.Л. Стиральные машины от А до Я

Огарков Н.В. Строчные трансформаторы зарубежных телевизоров и их аналоги. Справочник

Родин А.В. Заправка картриджей современных принтеров

Садченков Д.А. Современные цифровые мультиметры

Столовых А.М. Практические советы по ремонту бытовой радиоэлектронной аппаратуры

Столовых А.М. Практические советы по ремонту бытовой радиоэлектронной аппаратуры. Книга 2

Ульрих В.А. Микроконтроллеры PIC16X7XX

Хрусталев Д.А. Ремонт сотовых телефонов

Яковлев В.Ф. Диагностика электронных систем автомобиля. Учебное пособие



Название: Библиотека домашнего мастера, ремонта, инженера, самоделкина - Сборник 95 книг

Год: 2002-2014

Издательство: Солон-Пресс, РИПОЛ Классик, и др.

Жанр: Электроника, ремонт, строительство

Формат: PDF,DJVU,FB2,EPUB,DOC

Качество: Отличное

Иллюстрации: Черно-белые, цветные

Размер: 867.3 Мб



Скачать: Библиотека домашнего мастера, ремонта, инженера, самоделкина - Сборник 95 книг (2002-2014) PDF, DJVU, FB2, EPUB, DOC



Скачать | Download | TurboBit.net

http://turbobit.net/mydyghp9prpb/Biblioteka_domashnego_mastera.rar.html



Скачать | Download | HitFile.net

http://www.hitfile.net/AzVfKo5/Biblioteka_domashnego_mastera.rar.html



Скачать | Download | Файлообменник.рф

http://файлообменник.рф/olafr5c583oh/Biblioteka_domashnego_mastera.rar.html



Скачать | Download | DataFile.com

http://www.datafile.com/d/TVRjMk56YzVNVFEF9/Biblioteka_domashnego_mastera.rar



 



Подписка на новости сайта…

http://feeds.feedburner.com/Soft-Labirint

http://feeds.feedburner.com/Soft-Labirint?format=xml

https://feedburner.google.com/fb/a/mailverify?uri=Soft-Labirint



 



 

Метки:   Комментарии (0)КомментироватьВ цитатник или сообщество
PrazdNik

Скачать книгу LADA Kalina двигатели 1.6і (8V), 1.4i (16V), 1.6i (16V) с каталогом деталей бесплатно в форматах fb2, txt, epub, rtf, pdf

Воскресенье, 24 Апреля 2016 г. 18:30 (ссылка)
avtorukovodstva.my1.ru/load/vaz/11


LADA Kalina двигатели 1.6і (8V), 1.4i (16V), 1.6i (16V) с каталогом деталей . Краткое содержание: LADA Kalina двигатели 1.6і (8V), 1.4i (16V), 1.6i (16V) с каталогом деталей Седан, универсал, хетчбэк.Эксплуатация, обслуживание, ремонт. Руководство по ремонту, эксплуатации и техническому

Комментарии (0)КомментироватьВ цитатник или сообщество

Следующие 30  »

<эксплуатация - Самое интересное в блогах

Страницы: [1] 2 3 ..
.. 10

LiveInternet.Ru Ссылки: на главную|почта|знакомства|одноклассники|фото|открытки|тесты|чат
О проекте: помощь|контакты|разместить рекламу|версия для pda