Перейти к содержимому
Калькуляторы
ребята давайте жить дружно? тут сам Jab признается что уже усе с 1PC на 4 дома покончено, а уже стоит коммутатор L3, так что через 5 лет будет работать Jab на Juniper пересядет...

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

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

что каждый писюк обошелся в 200$ ( я даже где-то статью писал тут ), то нехилое получилось капиталовложение. :-)

 

А из гигабитных рутеров потом какие-нибудь NAS'ы пособираем, или опять офисные тачки.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Итак, подведу небольшой итог дискуссии, которая все-таки в том или ином виде состоялась, и заодно отвечу на вопрос камрада AlexBT.

 

Холливар никто не устраивал, хотя некоторые зеленые юнцы и даже (или как всегда?) jab, невнимательно прочитав тему, пытались склонить ее к холливару. Я же привел некоторые тезисы, которые объясняли, почему бессмысленно сравнивать коробки вендора и решения на базе opensource по такому параметру, как производительность. Любопытно, что некоторые высказавшиеся товарищи, судя по всему, не прочитавшие тему целиком, писали схожие с моими идеи, тезисы и даже выводы.

 

Еще раз подчеркну, что я совершенно не отрицаю возможность построения сетей на opensource-решениях, возможную успешность и конкурентноспособность таких сетей. Но, вместе с тем, мои выводы объясняют тот факт, почему, несмотря на некоторые бросающиеся в глаза преимущества, решения на opensource не очень широко распространены в целом, проктически никогда не встречаются в операторах больше определенного размера (если не разделять понятия "оператор" и "домашняя сеть" или "провайдер Интернет"), а также практически совершенно не встречаются в энтерпрайзе. Я сгруппировал уже высказанные, но разрозненные по теме тезисы в едином месте и разбил их на две части. Первая часть, "видение инженера", включает в себя тезисы, актуальные для инженерно-технического персонала, вторая часть называется "видение менеджера" и представляе тезисы, которые актуальны для IT-менеджера (CIO).

 

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

 

Чего я прошу НЕ ДЕЛАТЬ:

1. Не начинать банальный холливар мегапакетами, фичами-багами и прочим. Давайте попробуем быть ближе к бизнесу;

2. Приводить опровержение одного-двух моих тезисов и довольно трубить, что все тезисы ни к черту не годятся. Я прекрасно понимаю, что по некоторым тезисам можно попытаться найти какое-либо исключение, которое, на самом деле, только подтверждает правило. Не забывайте, что для успешности решения важна сбалансированность показателей (прямо как в корме для собак) и несколько опровергнутых доводов все равно общей картины не изменят;

3. Высказываться в духе "мнение аффтара такая бредятина, что ее даже комментировать не надо, и вообще кг/ам" - аргументируйте, если есть чем, или не отнимайте у других время;

4. Писать бессмысленные посты и тупо флудить. Я читаю форум через GPRS на КПК, жалко экран наладонника - протирается из-за скроллинга :-(

 

Итак, обещанные доводы:

 

Недостатки решений на базе Opensource с точки зрения инженерно-технического персонала:

 

- для того, чтобы обеспечить функциональность устройства, необходимо собирать образ, состоящий из многих различных компонентов, взаимная работоспособость которых никем не проверялась и никем не гарантируется;

- никто НЕ ОБЯЗАН решать проблемы с софтом, а может это делать только по собственному желанию;

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

- система настраивается многими конфигурационными файлами - нет единой консоли для настройки и управления;

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

- отсутствуют рекомендации по дизайну (а-ля SRND или SAFE у Cisco) - дизайн решения выбирается на свой страх и риск;

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

 

Недостатки решений на базе Opensource для IT-директора (CIO):

- решение как таковое отсутствует - есть только коробка;

- удельные характеристики коробки неясны (производительность, например), за них никто не отвечает;

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

- далеко не все оборудование имеет необходимые сертификаты;

- для того, чтобы решить задачи типичного энтерпрайза, необходимо отдельно закупать l2- и l3- коммутаторы от некоего вендора, отдельно телефонную станцию, отдельно маршрутизаторы на opensource - затраты на эксплуатацию возрастают;

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

- в обоих случаях (оператор и энтерпрайз) непонятно, чем и как управлять этой системой, состоящей из множества разнообразного оборудования;

- из-за малого количества адекватных специалистов на кадровом рынке резко возрастают риски зависимости от персонала;

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

 

 

Три, два, один... Fight! :-))

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

 

p.s. особенно они любят фотографировать ;)

Изменено пользователем ingress

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

С точки зрения серьезного телекома могу Полностью согласится с Nailer, c точки зрения начинающей сети то опенсоурс единственный выход...

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

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

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

 

Все ентерпрайзы и нормальный телеком готов заплатить за "мозги" персонала, за простоту решения, за повторяемость этого решения, за гарантию на железку… стоимость железки 800$ или 2800$ начинает быть неважной, так как повышается качество сервиса и быстрота внедрения этого сервиса, и эти 2000$ начинают оправдывать себя через неделю, а если это сделать на опенсоурс то начинается гадание заработает через 5 минут? или через 5 часов эротических приключений?..

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

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

технологии построили монстра, который убил альтависту, и отгрыз половину стартапа в котором работает мой коллега. :-)

 

Поэтому когда тут рассказывают про размеры местных телекомов, это даже не смешно, это кругозор у людей такой. "Дальше Риги не бывал, слаще репы не едал".

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообще интересное наблюдение.

 

Когда общаешься со старыми системщиками, заставшими ещё ЕС и СМ, то они говорят, что на них нельзя было считаться программистом, если ты не знал ассемблера.

 

А теперь же, даже уже на уровне директоров компаний люди боятся поставить сервер на стандартейших и очень хорошо описанных Linux-е/FreeBSD с Zebra/Quagga, так как его некому будет обслуживать.

 

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

И то я сомневаюсь, чтоб у них на это хватило квалификации.

 

Подумайте над этим.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Когда общаешься со старыми системщиками, заставшими ещё ЕС и СМ, то они говорят, что на них нельзя было считаться программистом, если ты не знал ассемблера.

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

 

Обычные программисты могли этого ничего не знать, а спокойно кропать на Fortran IV, PL/1, или на Коболе, который ( как и Линукс ) вызывает необратимые изменения мозга. :-)

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

 

Однако, тынденция. :(

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вообще интересное наблюдение.

 

Когда общаешься со старыми системщиками, заставшими ещё ЕС и СМ, то они говорят, что на них нельзя было считаться программистом, если ты не знал ассемблера.

 

А теперь же, даже уже на уровне директоров компаний люди боятся поставить сервер на стандартейших и очень хорошо описанных Linux-е/FreeBSD с Zebra/Quagga, так как его некому будет обслуживать.

 

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

И то я сомневаюсь, чтоб у них на это хватило квалификации.

 

Подумайте над этим.

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

 

Тоже самое со "стандартными и хорошо описанными Linux-е/FreeBSD с Zebra/Quagga", кроме них можно поставить кучу НЕ стандартных и НЕ хорошо описанных пакетов, с которыми последующим поколениям будет не так просто разбираться.

 

Как Вы думаете, если, уважаемый, jab сейчас плюнет на свою контору и уйдет в другую, через какое время его смогут полностью замень?

 

По поводу обезьян - это не тенденция, это нормальный выход из сложившейся ситуации. UglyAdmin, кто кроме Вас в Вашей сети сможет правильно диагностировать проблему клиента? Уверен, что никто. И что? Вас сажать на суппорт? А стандартные ситуации Ваш суппорт по бумажке обычно решает.

Изменено пользователем gorbaty

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

- для того, чтобы обеспечить функциональность устройства, необходимо собирать образ, состоящий из многих различных компонентов, взаимная работоспособость которых никем не проверялась и никем не гарантируется;
Неверно. Во первых на многие компоненты есть техническая спецификация для начала. Во вторых если хочется немного документированности - есть HCL от Redhat например.

 

- никто НЕ ОБЯЗАН решать проблемы с софтом, а может это делать только по собственному желанию;
По факту - например специалист который общается скажем в netdev maillist - может очень оперативно решить проблемы. Более того, на собственном примере, предложив необходимую фичу - я получил _новый_ функционал в очень сжатые сроки и _бесплатно_, если не считать собственное время. Если вкратце - все зависит от вашей же гибкости.

 

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

 

- система настраивается многими конфигурационными файлами - нет единой консоли для настройки и управления;
В случае системы с исходным кодом - есть выбор. Можно и единую консоль, по желанию заказчика. Можно ее сделать идентичной Cisco CLI, можно и подточить даже под функциональность SNMP Cisco ucd-snmp - если хочется, я такое делал. В случае некоторых заказчиков - это необходимо, если у них четко описанный круг задач, программеров нет, и есть только цисководы, которых переучивать не планируется.

 

- инженеру необходимо быть не только специалистом в сетевых технологиях, но и детально разбираться в ядре операционной системы, прикладном софте для реализации различной функциональности. Другими словами, гонщик должен быть не только гонщиком, но и талантливым автомехаником и конструктором;
Кесарю-кесарево. Нужна просто слаженная работа разработчиков, тестеров и эксплуатационщиков. Конечно это увеличивает штат интегратора, но в этом случае он выглядит более серьезно, чем кодла менеджеров, которая ничем не занимается, чем как по готовым мануалам copy&paste что нужно купить... ну может еще кучка мальчиков-побегайчиков, которые кабеля обжимают.

 

- отсутствуют рекомендации по дизайну (а-ля SRND или SAFE у Cisco) - дизайн решения выбирается на свой страх и риск;
Не спорю, можно пошевелить собственными мозгами, а можно выбрать все по бумажке. Страх и риск заключается в конечном счете коммерческой выгоде. В этом мире если ты не шевелишь собственными мозгами - платишь кому-то, кто за тебя ими пошевелил. Чудес не бывает.

 

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

 

- решение как таковое отсутствует - есть только коробка;
Есть и коробочные решения. Но не для всех направлений.

 

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

 

- невозможно обучить персонал - курсов, внятной системы сертификации, достаточного количества специалистов на рынке нет;
Я не в курсе насчет сертификации для RH, скажем в России, но она есть и работает.

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

 

- далеко не все оборудование имеет необходимые сертификаты;
Несколько специфичная для России проблема. Тут я не советчик.

 

- для того, чтобы решить задачи типичного энтерпрайза, необходимо отдельно закупать l2- и l3- коммутаторы от некоего вендора, отдельно телефонную станцию, отдельно маршрутизаторы на opensource - затраты на эксплуатацию возрастают;
Свобода выбора никогда не осуждалась. Необходимо - неправильное слово, никто не мешает применять совместно с Linux роутерами - L2 свичи от Cisco. Естественно прыгать из-за копейки и создавать зоопарк не стоит, риск,выгоду,эксплуатационные расходы нужно оценивать в каждом случае.

 

- для решения задач оператора необходимы отдельные коммутаторы, устройства для работы с TDM/SDH, отдельные каналообразующие устройства;
Зависит от конкретно поставленной технической задачи. В некоторых случаях действительно надежных альтернатив Cisco нет, не стоит пихать "любимое" железо или решение в каждую дырку.

 

- в обоих случаях (оператор и энтерпрайз) непонятно, чем и как управлять этой системой, состоящей из множества разнообразного оборудования;
Как и выше - система управления может быть создана по задаче заказчика. В большинстве случаев это "посильная" задача.

 

- из-за малого количества адекватных специалистов на кадровом рынке резко возрастают риски зависимости от персонала;
Все зависит от кадровиков, правильно поставленной начальной задачи, т.к. _решение_ не должно сильно зависеть от специалистов. Можно и на циске построить так - что все будет зависеть от специалистов-гениев.

 

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

 

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

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Когда общаешься со старыми системщиками, заставшими ещё ЕС и СМ, то они говорят, что на них нельзя было считаться программистом, если ты не знал ассемблера.

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

 

Обычные программисты могли этого ничего не знать, а спокойно кропать на Fortran IV, PL/1, или на Коболе, который ( как и Линукс ) вызывает необратимые изменения мозга. :-)

Земная FreeBSD вызывает аналогичные по симптоматике изменения даже у инопланетян.

Эти штуки забористые :)

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Как Вы думаете, если, уважаемый, jab сейчас плюнет на свою контору и уйдет в другую, через какое время его смогут полностью замень?

Вы действительно думаете что я тут один такой ? :-) Или думаете что я что-то делаю сам ? Для этого есть группа вполне взаимозаменяемых

админов. Мое дело было - отладить технологию, дальше это все будет несколько лет катиться на автомате.

 

Недостатки решений на базе Opensource с точки зрения инженерно-технического персонала:

...

Недостатки решений на базе Opensource для IT-директора (CIO):

38. Трудно получить откат.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

- для того, чтобы обеспечить функциональность устройства, необходимо собирать образ, состоящий из многих различных компонентов, взаимная работоспособость которых никем не проверялась и никем не гарантируется;
Неверно. Во первых на многие компоненты есть техническая спецификация для начала. Во вторых если хочется немного документированности - есть HCL от Redhat например.

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

 

- никто НЕ ОБЯЗАН решать проблемы с софтом, а может это делать только по собственному желанию;
По факту - например специалист который общается скажем в netdev maillist - может очень оперативно решить проблемы. Более того, на собственном примере, предложив необходимую фичу - я получил _новый_ функционал в очень сжатые сроки и _бесплатно_, если не считать собственное время. Если вкратце - все зависит от вашей же гибкости.

Не отрицаю, что решить проблему можно. Но опять же - ключевое слово тезиса "НЕ ОБЯЗАН". Понятие "может" ("хочет", "интересно" и т.д.) и "обязан" несколько разного порядка. Закладываться в бизнесе на то, что кто-то "может" и механизма принуждения к "должен"не существует, будет далеко не каждый.

 

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

Опять все упирается в компетенции инженеров. Среднестатистический сетевик не разберется в чужом, малопонятном коде на C. Кроме того, разбирательство в чужом коде может занять весьма значительное время.

 

Здесь, кстати, есть два дополнительных довода в пользу закрытого кода. Во-первых, взломщик в случае атаки так же легко получит доступ к исходным кодам системы, как и вы сами, и вполне способен самостоятельно разработать новый эксплоит. А во-вторых, тезис, который пивел zoro - открытый код ПО, разрозненность источников ПО позволяет сотруднику легко оставить закладки и использовать их по любому назначению (сам так делал в свое время, правда, в мирных целях" :-) ), и сильно затрудняет или делает почти невозможным аудит.

 

- система настраивается многими конфигурационными файлами - нет единой консоли для настройки и управления;
В случае системы с исходным кодом - есть выбор. Можно и единую консоль, по желанию заказчика. Можно ее сделать идентичной Cisco CLI, можно и подточить даже под функциональность SNMP Cisco ucd-snmp - если хочется, я такое делал. В случае некоторых заказчиков - это необходимо, если у них четко описанный круг задач, программеров нет, и есть только цисководы, которых переучивать не планируется.

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

 

- инженеру необходимо быть не только специалистом в сетевых технологиях, но и детально разбираться в ядре операционной системы, прикладном софте для реализации различной функциональности. Другими словами, гонщик должен быть не только гонщиком, но и талантливым автомехаником и конструктором;
Кесарю-кесарево. Нужна просто слаженная работа разработчиков, тестеров и эксплуатационщиков. Конечно это увеличивает штат интегратора, но в этом случае он выглядит более серьезно, чем кодла менеджеров, которая ничем не занимается, чем как по готовым мануалам copy&paste что нужно купить... ну может еще кучка мальчиков-побегайчиков, которые кабеля обжимают.

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

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

 

- отсутствуют рекомендации по дизайну (а-ля SRND или SAFE у Cisco) - дизайн решения выбирается на свой страх и риск;
Не спорю, можно пошевелить собственными мозгами, а можно выбрать все по бумажке. Страх и риск заключается в конечном счете коммерческой выгоде. В этом мире если ты не шевелишь собственными мозгами - платишь кому-то, кто за тебя ими пошевелил. Чудес не бывает.

Большинство инвесторов предпочитают не покупать кота в мешке, и готовы заплатить за то, что понимают, что получат в результате. А коммерческая выгода, даже для оператора (не говоря уж об энтерпрайзах), как правило, очень далека от технических параметров системы и лежит ближе к правильному маркетингу. Со стороны it требуется минимизировать затраты, обеспечить гибкость и высокую скорость реакции на требования бизнеса. И все :-)

Причем этой гибкостью может быть не только новый функционал, но и обсуждавшийся запас по производительности. Скажем, ethernet им обладал, а вот с ADSL в него уперлись и меняли DSLAM-ы, чтобы дать полосы шире.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

В том-то и вопрос, будет ли этот уровень приходится на вас или останется головной болью вендора.

 

- решение как таковое отсутствует - есть только коробка;
Есть и коробочные решения. Но не для всех направлений.

Бесплатные? :-)

 

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

А что, по вашему, в случае проблемы с вендорской коробкой ее можно только заменить целиком? :-) Такими же костылями все решается, как и с opensource. А вот самому исправить проблему можно только в случае, если в штате есть инженер, который глубоко разбирается в программинге - а про это см. выше.

 

- невозможно обучить персонал - курсов, внятной системы сертификации, достаточного количества специалистов на рынке нет;
Я не в курсе насчет сертификации для RH, скажем в России, но она есть и работает.

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

Все смешалось в доме Облонских - затачивать систему под специалистов это какой-то бред, в современном мире система затачивается под задачи бизнеса, причем обслуживающий персонал на самом деле является частью системы, и его компетенции, количество персонала, режимы работы, функциональнальные обязанности проектируются в месте с ней (см. ГОСТ 34.*). Я в свое время в техпроектах даже рекомендованные курсы и сертификации прописывал, чтобы заказчики не ломали головы.

RedHat давно уже встал на коммерческие рельсы, и поэтому очень правильно то, что они сделали, введя сертификацию. Но мы вроде про бесплатные решения говорим, имея в виду opensource, а не только те, код которых можно прочитать? :-) А то в сети исходники IOS мохнатых версий валялись ;-)

 

- далеко не все оборудование имеет необходимые сертификаты;
Несколько специфичная для России проблема. Тут я не советчик.

В Европу не ROHS-оборудование ввозить уже нельзя, не то что эксплуатировать. Не думаю, что остальные сертификаты давались только ради бумажки. Ситуация скорее по-другому выглядит у вас, чем в Росии и остальном мире.

 

- для того, чтобы решить задачи типичного энтерпрайза, необходимо отдельно закупать l2- и l3- коммутаторы от некоего вендора, отдельно телефонную станцию, отдельно маршрутизаторы на opensource - затраты на эксплуатацию возрастают;
Свобода выбора никогда не осуждалась. Необходимо - неправильное слово, никто не мешает применять совместно с Linux роутерами - L2 свичи от Cisco. Естественно прыгать из-за копейки и создавать зоопарк не стоит, риск,выгоду,эксплуатационные расходы нужно оценивать в каждом случае.

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

 

- для решения задач оператора необходимы отдельные коммутаторы, устройства для работы с TDM/SDH, отдельные каналообразующие устройства;
Зависит от конкретно поставленной технической задачи. В некоторых случаях действительно надежных альтернатив Cisco нет, не стоит пихать "любимое" железо или решение в каждую дырку.

 

- в обоих случаях (оператор и энтерпрайз) непонятно, чем и как управлять этой системой, состоящей из множества разнообразного оборудования;
Как и выше - система управления может быть создана по задаче заказчика. В большинстве случаев это "посильная" задача.

Время, стоимость создания, поддержка уникальной системы, специалисты по системе? Опять же - разработать можно и cisco ios - принципиальная возможность такой разработки доказана, дело за малым - начать и кончить :-)

 

- из-за малого количества адекватных специалистов на кадровом рынке резко возрастают риски зависимости от персонала;
Все зависит от кадровиков, правильно поставленной начальной задачи, т.к. _решение_ не должно сильно зависеть от специалистов. Можно и на циске построить так - что все будет зависеть от специалистов-гениев.

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

 

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

Где их взять простому CIO? :-) С каким количеством head developers надо иметь контакт - по одному от каждого используемого пакета? Что они вам должны, если большинство софта поставляется "as is"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

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

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

 

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

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

 

Кстати, параллельный и не относящийся к теме маленький оффтопик - расскажите, как осуществляется процесс форвардинга пакетов в linux/bsd? Давно было интересно, но копать было некогда, да и не очень понятно где :-)

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Посыл тезиса несколько другой - взаимная работоспособость кем-то проверяетсяи и, более того, гарантируется? Частные разработчики обладают широкой материально-технической базой для проведения полноценного тестирования? Спецификация необходима в любом случае хотя бы для возможности самой разработки, но вовсе не гарантирует того, что все будет работать так, как в ней описано.
Проверяется. Community. И базируется на отзывах о реальной эксплуатации, а не стендовых испытаниях.

 

Не отрицаю, что решить проблему можно. Но опять же - ключевое слово тезиса "НЕ ОБЯЗАН". Понятие "может" ("хочет", "интересно" и т.д.) и "обязан" несколько разного порядка. Закладываться в бизнесе на то, что кто-то "может" и механизма принуждения к "должен"не существует, будет далеко не каждый.
А еще есть ситуация, "вендор/интегратор выкрутился/открутился от проблемы"+"решить больше некому", отпиской мелким шрифтом.

 

 

 

Опять все упирается в компетенции инженеров. Среднестатистический сетевик не разберется в чужом, малопонятном коде на C. Кроме того, разбирательство в чужом коде может занять весьма значительное время.
Одно из требований опенсурса - понятный код. И сразу видно - хорошо программа написана, или нет. А IOS который пишется в оутсорсе в Индии последнее время отличается особой "стабильностью".

 

Здесь, кстати, есть два дополнительных довода в пользу закрытого кода. Во-первых, взломщик в случае атаки так же легко получит доступ к исходным кодам системы, как и вы сами, и вполне способен самостоятельно разработать новый эксплоит. А во-вторых, тезис, который пивел zoro - открытый код ПО, разрозненность источников ПО позволяет сотруднику легко оставить закладки и использовать их по любому назначению (сам так делал в свое время, правда, в мирных целях" :-) ), и сильно затрудняет или делает почти невозможным аудит.
1)Это один из самый распространенных тезисов сторонников закрытого ПО.
Доступность исходного кода — палка о двух концах. Сообщество хакеров может использовать анализ кода для поиска уязвимостей. В свою очередь, сообщество разработчиков способно поддерживать и улучшать код, применять формализованные методологии испытаний, чтобы обнаруживать и исправлять дефекты программного обеспечения прежде, чем ими смогут воспользоваться злоумышленники. Сообщество пользователей может задействовать исходный код для обнаружения и предотвращения атак, причем после выявления недостатков удается быстро устранять уязвимости и публиковать исправления. Имея дело с закрытой системой, потребители полностью зависят от способности поставщика быстро обнаруживать уязвимости, разрабатывать и рассылать исправления.
Если скажем бинарный код вашей системы собранной конкретно под ваше железо может быть персонифицирован, то IOS общедоступен, и если в нем появляется эксплоит - он применим к широкому кругу систем. Кроме того отсутствие исходного кода не отменяет ассемблер.

 

При доскональном документировании изменений в системе (version control),правильном распределении правил доступа и слаженной системе бекапа - внесение закладок невозможно.

 

Разработать можно все, что угодно, но мы говорим о сложившейся на данный момент ситуации, а на данный момент такого варианта не существует.
Возьмите к примеру Mikrotik. Вот и вариант. Управление по SSH, telnet, есть свой унифицированный стиль CLI, конфигурации , есть курсы, сертификация , ВСЕ пакеты загнаны под эту систему управления. Отлично поддается централизации (собственный опыт). Поддерживает нормальный AAA, экспорт конфигураций... это как пример. Можно копнуть глубже если надо.

 

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

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

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

 

А я знаю.

 

 

Большинство инвесторов предпочитают не покупать кота в мешке, и готовы заплатить за то, что понимают, что получат в результате. А коммерческая выгода, даже для оператора (не говоря уж об энтерпрайзах), как правило, очень далека от технических параметров системы и лежит ближе к правильному маркетингу. Со стороны it требуется минимизировать затраты, обеспечить гибкость и высокую скорость реакции на требования бизнеса. И все :-)

Причем этой гибкостью может быть не только новый функционал, но и обсуждавшийся запас по производительности. Скажем, ethernet им обладал, а вот с ADSL в него уперлись и меняли DSLAM-ы, чтобы дать полосы шире.

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

В том-то и вопрос, будет ли этот уровень приходится на вас или останется головной болью вендора.
Это все зависит от вендора.

 

Бесплатные? :-)
Бесплатные - без гарантий. Если уверен в собственных специалистах - можно полагаться и на такие.

Cisco не брезгует полагаться на бесплатные, и почему-то не использует "гарантированный" IIS у себя на основном сайте :-)

 

А что, по вашему, в случае проблемы с вендорской коробкой ее можно только заменить целиком? :-) Такими же костылями все решается, как и с opensource. А вот самому исправить проблему можно только в случае, если в штате есть инженер, который глубоко разбирается в программинге - а про это см. выше.
Зачем глубоко? Часто решение проблем тривиально.

А например, появилась задача сделать безопасный доступ к 2500 и 1700. SSH там "Cisco 2500 and 1700 series not being supported for performance reasons". И как вы эту задачу решите?

No the 25xx series does not...we are changing out all our 2511 routers

that we use for term servers

Прошу ответа на сей тривиальный пример, без замены оборудования, который в мире опенсурса решается проще пареной репы. Хоть там и 20 Mhz, хоть и NOMMU, но ssh сделать _реально_. Но не хотят.

 

Все смешалось в доме Облонских - затачивать систему под специалистов это какой-то бред, в современном мире система затачивается под задачи бизнеса, причем обслуживающий персонал на самом деле является частью системы, и его компетенции, количество персонала, режимы работы, функциональнальные обязанности проектируются в месте с ней (см. ГОСТ 34.*). Я в свое время в техпроектах даже рекомендованные курсы и сертификации прописывал, чтобы заказчики не ломали головы.

RedHat давно уже встал на коммерческие рельсы, и поэтому очень правильно то, что они сделали, введя сертификацию. Но мы вроде про бесплатные решения говорим, имея в виду opensource, а не только те, код которых можно прочитать? :-) А то в сети исходники IOS мохнатых версий валялись ;-)

Не всегда можно поставить условием набор или обучение необходимого персонала. Иногда требуется подстраиваться под существующие реалии.

Мы говорим про легальный _opensource_, а не бесплатные решения. Бесплатный только сыр в мышеловке.

И сертифицированный специалист RedHat вполне разберется с CentOS, если нужно. Который бесплатен.

 

В Европу не ROHS-оборудование ввозить уже нельзя, не то что эксплуатировать. Не думаю, что остальные сертификаты давались только ради бумажки. Ситуация скорее по-другому выглядит у вас, чем в Росии и остальном мире.
ROHS - это по железу. Больше головная боль для чипмейкеров. Ну еще есть сертификация по частотным излучениям. Это достаточно обоснованные вещи, одна из которых направлена на экологию, другая на стабильность функционирования оборудования.

 

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

 

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

А LDAP directory server? _железный_ сервер. У них есть только софт. А железо прийдется покупать у стороннего вендора.

 

А веб-сервер? Как странно, они сами пользуются опенсурцом.

Connected to www.cisco.com.

Escape character is '^]'.

HEAD / HTTP/1.1

 

HTTP/1.1 400 Bad Request

Date: Thu, 14 Aug 2008 21:34:30 GMT

Server: Apache/2.0

443/tcp open ssl/http Apache httpd 1.3.37 ((Unix) mod_ssl/2.8.28 OpenSSL/0.9.8d)

 

DNS серверы собственного производства наверное у них тоже есть?

Interesting ports on ns2.cisco.com (64.102.255.44):

PORT STATE SERVICE VERSION

53/tcp open domain ISC BIND Unavailable

 

А самое смешное, почтовый сервер!

Какая досада: 25/tcp open smtp Sendmail 8.11.7p3+Sun

 

И весь этот софт отнюдь не Cisco писан. И полагаются они как раз на тех самых "ненадежных" опенсорс разработчиков.

 

 

Время, стоимость создания, поддержка уникальной системы, специалисты по системе? Опять же - разработать можно и cisco ios - принципиальная возможность такой разработки доказана, дело за малым - начать и кончить :-)
Зачем уникальной? Есть определенные устоявшиеся стандарты.

 

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

 

Где их взять простому CIO? :-) С каким количеством head developers надо иметь контакт - по одному от каждого используемого пакета? Что они вам должны, если большинство софта поставляется "as is"?
Они? Да по сути ничего, но нерешенных проблем с опенсурсом у меня не было. А вот отмороженных вендоров с закрытым кодом - хоть лопатой греби, особенно если они понимают, что ты от них зависишь, и ты встрял из-за их ляпа, и деваться тебе некуда(предпочтешь поддаться их требованиям, чтоб поскорее решить проблему) - то стрясут все что можно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Кстати, параллельный и не относящийся к теме маленький оффтопик - расскажите, как осуществляется процесс форвардинга пакетов в linux/bsd? Давно было интересно, но копать было некогда, да и не очень понятно где :-)
Вам в какой части? Именно сам пакет? Структуры? Какой codepath через netfilter/bridge? Как обрабатывается аппаратно?

Это очень широкая сфера... если есть конкретные вопросы - могу пояснить.

 

Документы по теме:

http://www.ittc.ku.edu/~ashwinc/docs/Network_stack.pdf (2005-й год, но многое верно)

firewall http://ftp.gnumonks.org/pub/doc/packet-journey-2.4.html

Еще детали освещены http://people.netfilter.org/pablo/docs/login.pdf

Здесь вкратце по свежим ядрам http://svn.gnumonks.org/trunk/doc/packet-journey-2.6.xml

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Циска-шмиска :-D

http://www.securiteam.com/exploits/5RP0I20P5A.html

Multiple Cisco IOS Shellcodes

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

FreeBSD прохождение пакета:

http://nuclight.livejournal.com/124348.html

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

IMHO Linux-u светит перспективная роль магистрального роутера, лишь в том случае если основной рутилкой будет ASIC с TCAM, который будет оффлоадить.
Дак есть уже подобное.

На базе Linux -- маршрутизаторы с IOS XE у Cisco.

На FreeBSD -- Juniper. (там правда не совсем TCAM, но не суть)

 

visir, Вы извините конечно, но БСД в Жунипере только как Control Plane, вся обработка пакетов происходит в ASIС....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

IMHO Linux-u светит перспективная роль магистрального роутера, лишь в том случае если основной рутилкой будет ASIC с TCAM, который будет оффлоадить.
Дак есть уже подобное.

На базе Linux -- маршрутизаторы с IOS XE у Cisco.

На FreeBSD -- Juniper. (там правда не совсем TCAM, но не суть)

 

visir, Вы извините конечно, но БСД в Жунипере только как Control Plane, вся обработка пакетов происходит в ASIС....

Эээ стоп J-серия без asic...M-серия и выше там уже да...

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Опенсурс - спасение при открытии "новых" сервисов.

 

Идей реализованых в бренд-вендорами на порядок меньше - они годятся исключительно для магистралей (и умных щетчиков на них)

 

Согласен - проблем с системамми аля Cisco заметно меньше, но чтобы сказать что их совсем нет :(

 

поетому используем больше - микротик и RH, BSD - так как гоним исключительно IP - трафик. (есть и 7206, 7204)

 

Надежность сети "последней мили" лежит в области надежности електроснабжения (опенсурса хватит)

 

маштабировать узлы можна и нужно уровнем L2 и ессесно разбивать на кластеры по мощности и количеству севисов (на ОДИНАКОВУЮ !!!! величину) вот вам и решение проблем - замена ячейки может быть проведена почти любым оборудование (в том числе опенсурсом).

 

надежность же узлов зависит от количества независимых источников подачи трафика

 

а не обородувания - имхо дяде Феде с бульдозером наплевать чей кабель он копает.

 

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

 

Абсолютно выгодных ы невыгодных сервисов нет - есть их распределение по географиии.

 

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.