А ещё можно использовать софтовый видеомикшер vMix с обвязкой из тех же всеядных BlackMagic Intensity Pro. Дёшево и сердито. И может RTMP и множество других плюх.
По поводу свистков, всё зависит от того, где они будут стоять и сколько будет людей. У нас пару раз были проблемы при количестве народа в несколько тысяч в одном месте.
Мы в телевидении пользуемся специальным оборудованием для проведения прямых трансляций. Бывает стоечное исполнение, бывает мобильное. Как раз чтобы не задумывать о том, что где-то не будет интернета — он всегда с собой. А на такие короткие мероприятия можно и арендовать, а не покупать.
На входе понимают HD-SDI и HDMI. Я пользовался оборудованием AviWest и отечественным AirHD. Умеют стримить через любой RTMP сервер, YouTube, UStream и прочие.
А как данное утверждение соотносится с таким явлением как криптовалюта? Технология же тоже построена на открытых/закрытых ключах, которые по требованию нужно предоставить…
Помните анекдот про неуловимого Джо? Здесь ситуация такая же.
Это не потому, что всё так хорошо охраняется, а потому, что государство пока не владеет какой-либо ценной информацией в электронном виде. Но в ближайшее время обрастёт очень даже интересными базами… И вот тут посмотрим на утечки, учитывая, что почти каждый ПК в органах так или иначе подключен к сети интернет.
Конкретно в тексте у автора проблема именно в том, чтобы выбрать какую из функций start дёрнуть.
Обратите внимание, что классы Scanner и Printer оба реализуют функцию start. Тогда какую функцию start унаследует класс Copier? Та, что реализована классом Scanner? Или классом Printer? Не могут же они обе унаследоваться.
Ни у принтера, ни у сканера нет функционала копира, поэтому наследованием проблему копирования не решить. Поэтому у автора и проблема с архитектурой, а не с ограничениями ООП.
Я бы поставленную задачу решал как-то так:
class Copier: public Scanner, public Printer {
public:
void start() { Printer::start(); Scanner::start(); }
using Printer::print;
using Scanner::scan;
void copy() { Page *page = this->scan(); this->print(page); }
}
Только недавно перечитывал Страуструпа и там один из вариантов решения «проблемы ромба» на С++:
class Copier: public Scanner, public Printer {
public:
using Printer::start;
}
Сама статья больше похожа на проявление архитектурной проблемы. Неоправданное применение ООП там, где можно было обойтись ФП не означает того, что ООП — зло. И то, и другое — лишь инструменты. Молотком можно и дом построить, и голову проломить — от этого молоток хуже не становится.
Автор, Вами представлен один из многих подходов для реализации офисной инфраструктуры. Хорошо, конечно, что Вы имеете представление о том, какое время Вы допускаете на восстановление и, что именно для Вас важнее.
Но подавляющее большинство директоров в принципе этого не представляют. И системные администраторы плодят железки не потому, что они такие плохие. А, чаще всего потому, что директор сам в этом не разбирается, а все пинки и зуботычины из-за того, что накрылся один единственный собранный на коленке за три копейки из б/у оборудования сервер, достаются именно администратору.
По закону подлости оборудование выходит из строя именно тогда, когда «плановый» простой в 2-3 дня будет недопустим. И та же Ваша сопровождающая организация пожмёт плечами и скажет: «Вы выбрали такую инфраструктуру». И предъявить им будет нечего. На сисадмина хоть поорать можно, почему он не предусмотрел, что именно в этот момент накроется мать и не купил запасную.
Вы описали просто один из подходов к реализации инфраструктуры в определённых условиях. Он не хорош, он не плох — он один из. Его главный плюс в том, что для Вашей организации он достаточен.
Подходит ли он для всего малого бизнеса? Не думаю.
Только не дай бог Вашу статью прочитать другим директорам, которые возомнят себя ИТ-гуру после этого и будут требовать именно такую инфраструктуру, несмотря ни на что =)
Коллеги, мне кажется, что вы обсуждаете два подхода к обеспечению надёжности системы.
Первый подход заключается в уменьшении количества точек отказа (представлен автором, но не стоит забывать, что и один сервер в себе таит с десяток точек отказа), второй — резервирование узлов (которое увеличивает вероятность отказов, но снижает их влияние на систему).
Но, простите, это не взаимоисключающие, а взаимодополняющие подходы!
Обратите внимание, автор допускает перерыв в работе бизнеса 2-3 дня. За это время можно, даже находясь в регионе, слетать в Мск и привезти новый сервер!
Соответственно для некоторого бизнеса и такой вариант является достаточным. Для другого, возможно, будет даже избыточен, для третьего — недостаточен и т.д.
Коллеги, мне кажется, вы спорите о различных специалистах. Оставим на минуту то, что написано в дипломе и условно разделим специалистов на техников и инженеров.
Коллега прав, техника с поверхностным знанием Windows найти гораздо проще, чем со знанием Linux. Но и другой коллега прав, техник вполне успешно может совершать 90% работы по обслуживанию той или иной системы: он «знает» (скорее помнит), где нужно поставить галочку, какой провод выдернуть/вставить, на какую кнопку нажать, какой узел «планово» перезагрузить, «сделать файловую шару»,«поставить ад на виртуалке» и т.д., на этом моменте его и начинают путать с инженером.
Инженер же обладает глубинными познаниями о том КАК работают те или иные технологии. Инженер может не знать какую именно галочку нужно поставить в Windows, или какую команду выполнить в Linux, или что написать на оборудовании Cisco, чтобы обеспечить физическое резервирование и увеличение пропускной способности. Как оно будет называться (nic teaming, bonding, lacp...) — не важно, он знает КАК работает эта технология, поэтому уже через пару минут чтения документации «по ключевым словам» он уже втыкает провода в циску и, тихонько ругаясь, что-то непонятное пишет сначала в одной консоли, затем в другой.
Поэтому поднимать HA-кластер, планировать структуру AD, разворачивать сеть и т.д. должен специалист уровня инженер, лучше — системный инженер (т.к. он видит более общую картину). Техник же тоже может без особых проблем поднять кластер HA: по инструкции (вероятнее всего написанной инженером). И всем будет казаться: зачем нужен высокооплачиваемый инженер, если есть низкооплачиваемые «инженеры», которые делают то же самое.
И на этом моменте не надо путать смену одного инженера другим и смену инженера бюджетным «инженером»-техником.
Для продолжения дискуссии хотелось бы для себя кое-что уяснить, и внести правку:
1. Коллега, Вы имеете опыт боевого использования обеих систем виртуализации?
2. У меня имеется опыт использования в бою только VMWare, VirtualBox — дома. На Hyper-V у меня только в одной организации работает одинокая FreeBSD, поэтому я это опытом не считаю.
Сейчас я понимаю, что вызвал бурную реакция словом «безальтернативен», прошу прощения. Я несколько изменил формулировку, чтобы она больше соответствовала действительности.
У меня складывается впечатление, что Вы имеете большой опыт развёртывания систем на базе решения Windows. Либо, если есть опыт работы с обеими системами виртуализации, то тут уж я бы лучше Вас послушал на тему чем одна из них лучше, чем другая.
Я честно скажу, объективно сравнить две системы не могу. Да, я хотел использовать в ЦОД и ту и другую виртуализацию, чтобы можно было в т.ч. объективно рассуждать, но не успел.
По своим субъективным ощущениям, если опустить маркетинговые сравнения, мне VMWare нравится больше потому, что она на Linux. Что мне, в первую очередь, не нравится в Hyper-V? Windows Core.
Нет, я не злобный линуксоид, у меня даже есть сертификаты, что я самый что ни на есть сертифицированный Windows-админ. У меня достаточно большой опыт внедрения и эксплуатации различных систем на различных операционных системах. Я ненавижу настраивать Linux: пока настроишь с ума сойдешь. Но когда всё настроил — он ведёт себя очень предсказуемо. Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.
Обновления в обеих ОС — это вообще отдельная песнь льда и пламени: практически в каждой серии или кого-то убьют, или будет секс.
Но давайте не забывать, что и одно и другое — всего лишь инструменты. Поэтому для каждой ситуации решение должно выбираться индивидуально, а не только потому, что «раз я это знаю, значит этим и надо пользоваться». Хотя часто бывает, что и эта причина ставится во главу угла: смысл специалиста по windows заставлять сопровождать *nix и наоборот? если уж в компании есть хороший windows-админ, то лучше ему давать те инструменты, которыми он владеет в совершенстве, а не подставлять и потом говорить «тыжпрограммист!», когда что-то упало.
Лично мне на тот момент и сейчас было бы абсолютно всё равно на чём поднимать виртуализацию: VMWare или Hyper-V. У заказчика-работодателя был на тот момент приобретён VMWare, его нужно было заставить работать, я это и сделал. Если бы системы виртуализации не было — выбор, ввиду долгих конкурсных процедур и т.п., однозначно пал бы на любое бесплатное решение, но и тут выбор был бы необъективен, а навязан финансово-временными рамками.
Если бы у меня действительно была возможность выбирать, я бы пошёл по пути снижения вероятности выхода из строя по причине виртуализации и внедрил бы сразу две системы виртуализации (всё равно какие, лишь бы две, максимально непохожие друг на друга). И разделил бы резервируемые сервисы между ними (например, основной и резервный контроллеры домена). Чтобы если уж вдруг, в какой-то момент времени произойдёт какая-то неисправность (ошибка программиста ВМ, внешняя атака, ошибка администратора...) в одной системе виртуализации — вторая осталась работать. Но это, мне кажется, идеальный случай.
Так это же просто инструмент! Здесь он был применён из-за возможностей Fault Tolerance. То, что желаемое разошлось с действительностью — проблема скорее архитектуры приложения, чем VMWare. Но при некоторой доработке архитектуры приложения напильником его всё-таки можно использовать. А аналога у Hyper-V по-прежнему нет =)
Да, загрузка производилась с SAN, но с ней были проблемы, в т.ч. программно-аппаратные. Плюс это дало разделение выполнения и данных, что упростило и ускорило процесс поиска неисправностей.
Обладай я неограниченным ресурсом, стал бы я снова ставить гипервизор на флешки? Не думаю. Стал бы смешивать исполнение и данные? Не хотелось бы, но ситуации бывают разные.
Нет, со мной поставщики решений VMWare не общались, решение было принято до меня. =)
Не понимаю, почему у Вас желание сделать отказоустойчивый кластер вызывает такую негативную реакцию? Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же?
По поводу свистков, всё зависит от того, где они будут стоять и сколько будет людей. У нас пару раз были проблемы при количестве народа в несколько тысяч в одном месте.
На входе понимают HD-SDI и HDMI. Я пользовался оборудованием AviWest и отечественным AirHD. Умеют стримить через любой RTMP сервер, YouTube, UStream и прочие.
Жаль что их выпускать почти перестали, сам храню как зеницу ока флешку от qumo с выключателем. А в старые времена почти все флешки были с рубильником.
А теперь давайте пофантазируем на эту тему…
Это не потому, что всё так хорошо охраняется, а потому, что государство пока не владеет какой-либо ценной информацией в электронном виде. Но в ближайшее время обрастёт очень даже интересными базами… И вот тут посмотрим на утечки, учитывая, что почти каждый ПК в органах так или иначе подключен к сети интернет.
Ни у принтера, ни у сканера нет функционала копира, поэтому наследованием проблему копирования не решить. Поэтому у автора и проблема с архитектурой, а не с ограничениями ООП.
Я бы поставленную задачу решал как-то так:
Сама статья больше похожа на проявление архитектурной проблемы. Неоправданное применение ООП там, где можно было обойтись ФП не означает того, что ООП — зло. И то, и другое — лишь инструменты. Молотком можно и дом построить, и голову проломить — от этого молоток хуже не становится.
Только мне кажется, что опять грядёт время тарифов «1000 рублей за 1Гб в месяц»? =(
Но подавляющее большинство директоров в принципе этого не представляют. И системные администраторы плодят железки не потому, что они такие плохие. А, чаще всего потому, что директор сам в этом не разбирается, а все пинки и зуботычины из-за того, что накрылся один единственный собранный на коленке за три копейки из б/у оборудования сервер, достаются именно администратору.
По закону подлости оборудование выходит из строя именно тогда, когда «плановый» простой в 2-3 дня будет недопустим. И та же Ваша сопровождающая организация пожмёт плечами и скажет: «Вы выбрали такую инфраструктуру». И предъявить им будет нечего. На сисадмина хоть поорать можно, почему он не предусмотрел, что именно в этот момент накроется мать и не купил запасную.
Вы описали просто один из подходов к реализации инфраструктуры в определённых условиях. Он не хорош, он не плох — он один из. Его главный плюс в том, что для Вашей организации он достаточен.
Подходит ли он для всего малого бизнеса? Не думаю.
Только не дай бог Вашу статью прочитать другим директорам, которые возомнят себя ИТ-гуру после этого и будут требовать именно такую инфраструктуру, несмотря ни на что =)
Первый подход заключается в уменьшении количества точек отказа (представлен автором, но не стоит забывать, что и один сервер в себе таит с десяток точек отказа), второй — резервирование узлов (которое увеличивает вероятность отказов, но снижает их влияние на систему).
Но, простите, это не взаимоисключающие, а взаимодополняющие подходы!
Обратите внимание, автор допускает перерыв в работе бизнеса 2-3 дня. За это время можно, даже находясь в регионе, слетать в Мск и привезти новый сервер!
Соответственно для некоторого бизнеса и такой вариант является достаточным. Для другого, возможно, будет даже избыточен, для третьего — недостаточен и т.д.
Легко рассуждать о делегировании.
Является ли автор руководителем коллектива > 10 человек?
Коллега прав, техника с поверхностным знанием Windows найти гораздо проще, чем со знанием Linux. Но и другой коллега прав, техник вполне успешно может совершать 90% работы по обслуживанию той или иной системы: он «знает» (скорее помнит), где нужно поставить галочку, какой провод выдернуть/вставить, на какую кнопку нажать, какой узел «планово» перезагрузить, «сделать файловую шару»,«поставить ад на виртуалке» и т.д., на этом моменте его и начинают путать с инженером.
Инженер же обладает глубинными познаниями о том КАК работают те или иные технологии. Инженер может не знать какую именно галочку нужно поставить в Windows, или какую команду выполнить в Linux, или что написать на оборудовании Cisco, чтобы обеспечить физическое резервирование и увеличение пропускной способности. Как оно будет называться (nic teaming, bonding, lacp...) — не важно, он знает КАК работает эта технология, поэтому уже через пару минут чтения документации «по ключевым словам» он уже втыкает провода в циску и, тихонько ругаясь, что-то непонятное пишет сначала в одной консоли, затем в другой.
Поэтому поднимать HA-кластер, планировать структуру AD, разворачивать сеть и т.д. должен специалист уровня инженер, лучше — системный инженер (т.к. он видит более общую картину). Техник же тоже может без особых проблем поднять кластер HA: по инструкции (вероятнее всего написанной инженером). И всем будет казаться: зачем нужен высокооплачиваемый инженер, если есть низкооплачиваемые «инженеры», которые делают то же самое.
И на этом моменте не надо путать смену одного инженера другим и смену инженера бюджетным «инженером»-техником.
1. Коллега, Вы имеете опыт боевого использования обеих систем виртуализации?
2. У меня имеется опыт использования в бою только VMWare, VirtualBox — дома. На Hyper-V у меня только в одной организации работает одинокая FreeBSD, поэтому я это опытом не считаю.
Сейчас я понимаю, что вызвал бурную реакция словом «безальтернативен», прошу прощения. Я несколько изменил формулировку, чтобы она больше соответствовала действительности.
У меня складывается впечатление, что Вы имеете большой опыт развёртывания систем на базе решения Windows. Либо, если есть опыт работы с обеими системами виртуализации, то тут уж я бы лучше Вас послушал на тему чем одна из них лучше, чем другая.
Я честно скажу, объективно сравнить две системы не могу. Да, я хотел использовать в ЦОД и ту и другую виртуализацию, чтобы можно было в т.ч. объективно рассуждать, но не успел.
По своим субъективным ощущениям, если опустить маркетинговые сравнения, мне VMWare нравится больше потому, что она на Linux. Что мне, в первую очередь, не нравится в Hyper-V? Windows Core.
Нет, я не злобный линуксоид, у меня даже есть сертификаты, что я самый что ни на есть сертифицированный Windows-админ. У меня достаточно большой опыт внедрения и эксплуатации различных систем на различных операционных системах. Я ненавижу настраивать Linux: пока настроишь с ума сойдешь. Но когда всё настроил — он ведёт себя очень предсказуемо. Но также я ненавижу настроенный Windows: обязательно где-то забудешь снять/поставить галочку и система будет себя вести непредсказуемо, пока не найдёшь искомую галочку.
Обновления в обеих ОС — это вообще отдельная песнь льда и пламени: практически в каждой серии или кого-то убьют, или будет секс.
Но давайте не забывать, что и одно и другое — всего лишь инструменты. Поэтому для каждой ситуации решение должно выбираться индивидуально, а не только потому, что «раз я это знаю, значит этим и надо пользоваться». Хотя часто бывает, что и эта причина ставится во главу угла: смысл специалиста по windows заставлять сопровождать *nix и наоборот? если уж в компании есть хороший windows-админ, то лучше ему давать те инструменты, которыми он владеет в совершенстве, а не подставлять и потом говорить «тыжпрограммист!», когда что-то упало.
Лично мне на тот момент и сейчас было бы абсолютно всё равно на чём поднимать виртуализацию: VMWare или Hyper-V. У заказчика-работодателя был на тот момент приобретён VMWare, его нужно было заставить работать, я это и сделал. Если бы системы виртуализации не было — выбор, ввиду долгих конкурсных процедур и т.п., однозначно пал бы на любое бесплатное решение, но и тут выбор был бы необъективен, а навязан финансово-временными рамками.
Если бы у меня действительно была возможность выбирать, я бы пошёл по пути снижения вероятности выхода из строя по причине виртуализации и внедрил бы сразу две системы виртуализации (всё равно какие, лишь бы две, максимально непохожие друг на друга). И разделил бы резервируемые сервисы между ними (например, основной и резервный контроллеры домена). Чтобы если уж вдруг, в какой-то момент времени произойдёт какая-то неисправность (ошибка программиста ВМ, внешняя атака, ошибка администратора...) в одной системе виртуализации — вторая осталась работать. Но это, мне кажется, идеальный случай.
Так это же просто инструмент! Здесь он был применён из-за возможностей Fault Tolerance. То, что желаемое разошлось с действительностью — проблема скорее архитектуры приложения, чем VMWare. Но при некоторой доработке архитектуры приложения напильником его всё-таки можно использовать. А аналога у Hyper-V по-прежнему нет =)
Но тут-то я делал систему что называется «для себя», а меня вмварью не запугать =)
Я вообще рассчитывал задержаться в этой организации, т.к. нереализованных идей была масса…
Обладай я неограниченным ресурсом, стал бы я снова ставить гипервизор на флешки? Не думаю. Стал бы смешивать исполнение и данные? Не хотелось бы, но ситуации бывают разные.
Нет, со мной поставщики решений VMWare не общались, решение было принято до меня. =)
Не понимаю, почему у Вас желание сделать отказоустойчивый кластер вызывает такую негативную реакцию? Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же?