А как данное утверждение соотносится с таким явлением как криптовалюта? Технология же тоже построена на открытых/закрытых ключах, которые по требованию нужно предоставить…
Помните анекдот про неуловимого Джо? Здесь ситуация такая же.
Это не потому, что всё так хорошо охраняется, а потому, что государство пока не владеет какой-либо ценной информацией в электронном виде. Но в ближайшее время обрастёт очень даже интересными базами… И вот тут посмотрим на утечки, учитывая, что почти каждый ПК в органах так или иначе подключен к сети интернет.
Конкретно в тексте у автора проблема именно в том, чтобы выбрать какую из функций 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 не общались, решение было принято до меня. =)
Не понимаю, почему у Вас желание сделать отказоустойчивый кластер вызывает такую негативную реакцию? Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же?
1. На тестовом стенде Fault Tolerance я тестировал один из хардкорных вариантов: просто физически вынималось работающее лезвие, затем возвращалось. Понятно, что это не самый гуманный способ, но мне нужно было быть уверенным, что система не упадёт. И она не падала. Но это всё была «синтетика», как он себя поведёт в реальной системе — для меня тоже скорее вопрос, чем твёрдая уверенность. И мой мысленный эксперимент также не сулил ничего хорошего для FT.
Как показала практика, минутная пауза на старт системы для пользователей проходила не особо заметно. Все больше грешили на «отсутствие интернета».
2. Да, я имел в виду роль Hyper V.
3. С SAN была ещё одна очень «плавающая» проблема. До какой-то из версий прошивок контроллера, установленного в лезвиях, он сбоил и при перезагрузке не всегда видел назначенные ему LUN. Т.е. после загрузки гипервизора проблем я не помню, а вот на моменте так сказать инициализации BIOS — проблемы были. Это тоже было одним из факторов за перенос гипервизора на локальное хранилище.
4. Я не спорю, что не только VMWare занимались виртуализацией. У Microsoft виртуализация появилась ещё тогда, когда они приобрели Connectix Virtual PC, если мне не изменяет память. Также параллельно развивались VirtualBox, Parallels. Ну т.е. теоретически выбор был.
Но, повторюсь, одной из задач было поднятие FT. Маркетинг или нет — судить не хочу, но у одних FT был, у других нет, альтернативы по функционалу не было. И, в принципе, если бы не кривизна архитектуры ПО и возможность её горизонтально масштабировать — FT как минимум можно было бы запустить в бой. Также было ограничение по поддерживаем Hyper-V гостевым ОС, ESXi поддерживал большее количество гостевых ОС. Я вот сейчас точно не помню, но там было ещё какое-то ограничение на размер образа файловой системы, от которого VMWare избавилось раньше. Что-то было связано со значением в 2Тб, по-моему. Я так понимаю Вы более плотно работаете с Hyper-V, думаю Вы быстрее вспомните все различия того времени.
Доступно свежее сравнение гипервизоров, они идут практически ноздря в ноздрю, но т.к. у VMWare виртуализация — основной вид деятельность, мне кажется, что в частностях они слегка впереди. Но я боюсь, что это зарождается тема для холивара. В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.
5. По поводу «сырости» — Windows 2012 на тот момент только вышел. Если быть точнее, то на момент моего трудоустройства Windows 2012 только ещё планировался к выходу. Проблемы с ОС после выхода были и их было не мало.
Т.е. либо нужно было использовать заведомо устаревший гипервизор от 2008 R2, либо ждать и идти первым по граблям 2012…
6. В плане внедрения Вы меня несколько неправильно поняли. Инициатива появилась после трудоустройства. VMWare мне достался уже как факт на всех лезвиях. Когда приобретался Windows Datacenter — уже было понимание того, что какую-то часть лезвий целесообразно поднять на гипервизоре от Microsoft, хотя бы с точки зрения экономии на лицензиях гипервизоров. А под занавес работ и ESXi бесплатный появился.
Жаль что их выпускать почти перестали, сам храню как зеницу ока флешку от 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 не общались, решение было принято до меня. =)
Не понимаю, почему у Вас желание сделать отказоустойчивый кластер вызывает такую негативную реакцию? Вы не считаете, что отказоустойчивость нод кластера для важных систем — это хорошо? Понятное дело, что стоит вопрос в реализации… Но всё же?
Постараюсь прокомментировать по пунктам:
1. На тестовом стенде Fault Tolerance я тестировал один из хардкорных вариантов: просто физически вынималось работающее лезвие, затем возвращалось. Понятно, что это не самый гуманный способ, но мне нужно было быть уверенным, что система не упадёт. И она не падала. Но это всё была «синтетика», как он себя поведёт в реальной системе — для меня тоже скорее вопрос, чем твёрдая уверенность. И мой мысленный эксперимент также не сулил ничего хорошего для FT.
Как показала практика, минутная пауза на старт системы для пользователей проходила не особо заметно. Все больше грешили на «отсутствие интернета».
2. Да, я имел в виду роль Hyper V.
3. С SAN была ещё одна очень «плавающая» проблема. До какой-то из версий прошивок контроллера, установленного в лезвиях, он сбоил и при перезагрузке не всегда видел назначенные ему LUN. Т.е. после загрузки гипервизора проблем я не помню, а вот на моменте так сказать инициализации BIOS — проблемы были. Это тоже было одним из факторов за перенос гипервизора на локальное хранилище.
4. Я не спорю, что не только VMWare занимались виртуализацией. У Microsoft виртуализация появилась ещё тогда, когда они приобрели Connectix Virtual PC, если мне не изменяет память. Также параллельно развивались VirtualBox, Parallels. Ну т.е. теоретически выбор был.
Но, повторюсь, одной из задач было поднятие FT. Маркетинг или нет — судить не хочу, но у одних FT был, у других нет, альтернативы по функционалу не было. И, в принципе, если бы не кривизна архитектуры ПО и возможность её горизонтально масштабировать — FT как минимум можно было бы запустить в бой. Также было ограничение по поддерживаем Hyper-V гостевым ОС, ESXi поддерживал большее количество гостевых ОС. Я вот сейчас точно не помню, но там было ещё какое-то ограничение на размер образа файловой системы, от которого VMWare избавилось раньше. Что-то было связано со значением в 2Тб, по-моему. Я так понимаю Вы более плотно работаете с Hyper-V, думаю Вы быстрее вспомните все различия того времени.
Доступно свежее сравнение гипервизоров, они идут практически ноздря в ноздрю, но т.к. у VMWare виртуализация — основной вид деятельность, мне кажется, что в частностях они слегка впереди. Но я боюсь, что это зарождается тема для холивара. В итоге я считаю, что нужно выбирать исходя из текущих и планируемых потребностей в каждом случае индивидуально.
5. По поводу «сырости» — Windows 2012 на тот момент только вышел. Если быть точнее, то на момент моего трудоустройства Windows 2012 только ещё планировался к выходу. Проблемы с ОС после выхода были и их было не мало.
Т.е. либо нужно было использовать заведомо устаревший гипервизор от 2008 R2, либо ждать и идти первым по граблям 2012…
6. В плане внедрения Вы меня несколько неправильно поняли. Инициатива появилась после трудоустройства. VMWare мне достался уже как факт на всех лезвиях. Когда приобретался Windows Datacenter — уже было понимание того, что какую-то часть лезвий целесообразно поднять на гипервизоре от Microsoft, хотя бы с точки зрения экономии на лицензиях гипервизоров. А под занавес работ и ESXi бесплатный появился.