Главная Без рубрики, Новое мысли, Общее, Пятничная тема
  • Монолог в Шереметьево-2

    donskoj1 13 января, на 61-м году жизни скончался знаменитый российский программист Михаил Донской. Его имя стало известно всему миру благодаря шахматной программе “Каисса”, которая одержала победу среди шахматных программ в 1974 году. Но Михаил Донской был известен не только из-за создания этой шахматной программы. Он разработал систему управления базами данных ИНЕС, а также был автором и соавтор многих иных крупномасштабных IT-проектов.

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

  • Главная Новое мысли
    • Дорога в будущее… Направление itband.ru…

      • Рубрика: Новое
      • Автор: Илья Рудь
      • Дата: Friday 26 Jun 2009

      LAHCAKK5MNNCAA1JMK4CAGWXU8FCA7RJJ3XCA6ZZWAACAIPFK76CAKF0OJGCAOGSYZ3CA92B8ATCA932937CAJO69YACA2P1RH1CANV09JHCAAMG4AGCAC9BVKNCA0RYACDCA5EDUR9CAW1CQV8CAFMGP00Сегодня исполняется три месяца с момента запуска нашего проекта. Проекта где стараются жить авторским материалом с минимумом “copy-paste” и если уж не получается выкладывать что то уникальное, то пусть материал будет иметь понятный русский язык. Мы стараемся…

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

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

      Отдельная благодарность нашим друзьям, которые делятся своими статьями, в особенности постоянному «спонсору» Romx, автору блога по системам хранения данных NetApp.

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

      Будьте с нами, а мы будет для вас.

      Авторский Коллектив

      Сайта Itband.ru

    • Главная Новое мысли, Пятничная тема
      • Будущее Системного администратора. Ваши планы?

        • Рубрика: Новое
        • Автор: Илья Рудь
        • Дата: Thursday 18 Jun 2009

        img_70 Последнее время в рамках  чтения курсов много общался со студентами младших курсов технических вузов Москвы, ну и естественно болтали за жизнь. Кто куда планирует идти работать, кто в какую область, сколько денег кому надо ну и тому подобное. Было интересно послушать, в некоторые моменты угадывал  свои  мысли 6-7 летней давности. Но разговор пойдет немного о другом. Сейчас я слегка постарше, жизненный и рабочий опыт накоплен немаленький и можно скинув студенческие "розовые очки" проанализировать, что светит в перспективе системному администратору в России. (За другие страны не могу говорить.. просто не знаю)

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

      • Главная Storages, Новое Fibre Channel, iSCSI, Storages, мысли
        • Кризис – время искать оптимальные решения. Часть 2

          EMOTICON MONEY Почти всегда, начиная разговор с клиентом по поводу использования iSCSI вместо Fibre Channel, раз за разом я сталкиваюсь с одним упорным возражением:
          “Ну… хм… Это же медленно!”
          Ну, казалось бы, очевидно: FC это 4Gb/s, а iSCSI – 1Gb/s, “один” ведь в четыре раза меньше, чем “четыре” ведь так?
          Давайте разберем что здесь на самом деле “медленно” и медленно ли.
          Для определенности давайте рассматривать какую-нибудь реальную задачу.

          Вот пример:
          Требуется система хранения данных для консолидации данных 4 серверов, 1 файловый сервер и 3 сервера баз данных. Необходимо обеспечить двухпутевое отказоустойчивое подключение.

          Но сперва немного теории.
          Я уже писал на тему странного спутывания в восприятии совершенно разных параметров канала передачи данных: “полосы пропускания” (анг. “bandwith”) и “скорости” (анг. “speed”).
          Для интересующихся подробностями просто сошлюсь на ранее опубликованный пост, а остальным перескажу вкратце.

          “Скорость” канала передачи данных равна скорости света в соответствующей среде, и она постоянная, вне зависимости, используем мы 10Mb/s Ethernet или 16GB/s Infiniband.
          Переводя на аналогии из “повседневной жизни” это ограничение скорости на дороге – 100 km/h.
          Все автомобили по дороге передвигаются с разрешенной скоростью, и ее не превышают по причине физического ее ограничения на уровне физических констант.

          В чем же отличие?
          В полосе пропускания.
          Полоса пропускания – это “рядность автострады”, это способность пропустить через себя “много данных” сразу. Но многорядность автострады никак не ускоряет движение одинокого автомобиля, проезжающего раз в минуту.
          Несколько парадоксальный вывод, который я делал в том посте требует некоторого волевого усилия для осознания.

          Неважно, насколько “быстрым” (с какой ширины полосой пропускания) интерфейсом соединена ваша система хранения с сервером, если объемы обработки данных этим сервером не достигают потолка имеющейся полосы пропускания.
          Если скорость считывания и записи сервера с системы хранения, например, не превышают 10 Мбит/с, то совершенно неважно для быстродействия, используете ли вы 100Mbit/s Fast Ethernet, FC, Infiniband, или подставьте_любой_баззворд_из_презентации.

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

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

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

          Disk Read bytes/s 2700902/Average 63587550/Max
          Disk Write bytes/s 736811/Average 1616167/Max

          То есть, самый нагруженный сервер системы, в максимуме нагрузки, достигал порога чтения всего, примерно, в 60-65 мегабайт в секунду!
          Это всего лишь (в пике дневной нагрузки, прошу заметить!) около 55-60% от полосы пропускания одного интерфейса Gigabit Ethernet, или, в случае типовой нагрузки в 2.5-3MB/s, всего около 2-3% от полосы пропускания GigE!

          Возможно в данном случае мы упираемся в предел возможности локальных дисков серверов, на смену которым призвана встать система хранения, и сервер имеет большой запас по производительности, если мы обеспечим ему широкую полосу пропускания для данных? Но нет, показатель Disk Read/Write Queue редко когда превышает значение 8-9, что означает относительно слабо нагруженную дисковую подсистему, значит в дисковую производительность сервер практически не упирается.

          Итак, давайте посчитаем. В случае нашей рассмотренной выше небольшой IT-системы из четырех серверов, в случае выбора FC нам необходимы:
          1. по два однопортовых или по одному двухпортовому FC HBA на каждый сервер – 8 однопортовых или 4 двухпортовых (QLogic QLE2462 2port – 700$ * 4 = 2400$)
          2. два FC-коммутатора (недостаточно встроенных FC-портов для подключения всех 6 линков) допустим, пусть это будут массовые и недорогие Brocade 200E – 4000$ * 2 = 8000$.
          3. Лицензия на FC (в зависимости от выбранного массива цена варьируется, например для системы типа FAS2050 это около 1200$ для одноконтроллерной и 2400$ для двухконтроллерной, отказоустойчивой, “кластерной” системы)
          4. ПО поддержки многопутевости (стоит заметить, что в поставке Windows средство обеспечения многопутевости MPIO не поддерживает FC, только iSCSI, и использование MPIO с FC требует установки дополнительного программного модуля, так называемого DSM, обычно предлагаемого поставщиком решения системы хранения, он недорог, но тоже не 0$)
          5. Кабеля FC optical LC-LC для подключения серверов к коммутаторам (8 шт) и коммутаторов к массиву (2 шт) (LC-LC optical 5m – 50$ * 10 = 500$).
          6. затраты на монтаж и настройку (варьируется).
          Кажется ничего не забыл 🙂

          Итого, нетрудно видеть, только на возможность использования протокола Fibre Channel мы потратим по меньшей мере около 12-15 тысяч долларов! При этом, как я показал выше, эти 12 тысяч совершенно не увеличат производительность получившейся системы. Они потрачены исключительно “на понты”, на возможность бросить в разговоре с коллегами “а, мы тут файбер ченэл себе прикупили”. 🙂
          “Хороший понт дороже денег”, не спорю. 😉 Но 12 тысяч это 12 тысяч. Тем более в наше непростое время на дворе.
          Но если бы мы использовали эти, вполне существенные деньги, на что-нибудь действительно дающее реальный эффект, например на пару дополнительных серверов для других задач, премию сисадминам оплату услуг хорошего программиста-оптимизатора баз данных, или, например, в случае системы хранения данных, на дополнительные 10-12 дисков, то за те же деньги мы бы получили (см. ранее про IOPS дисков) систему хранения по меньшей мере на 1800-2500 IOPS быстрее!
          И только за счет отказа от “крутого”, “понтового”, но избыточного, и поэтому совершенно “неполезного” в данном случае Fibre Channel.

          Romx

          http://blog.aboutnetapp.ru/

        • Главная Storages, Новое ИТ инфраструктура, мысли
          • Кризис – хорошее время искать оптимальные решения

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

            Ну это наша традиционная болезнь. Чтобы уменьшить фотографию с пьянки нет лучше средства чем Adobe Photoshop CS3, а eсли ставить “венду” – то только Datacenter Edition. “Красть – так миллион, … так королеву” 🙂

            Компания, на которую сваливаются нежданные IT-бюджеты ведет себя как “новый русский” из анекдотов в магазине: “Принесите мне все САМОЕ дорогое! Плачу наличными!”. И если бы в самом деле платил 🙂 На деле понты не дают возможности купить не САМОЕ дорогое, а на дорогое денег… как бы… не особо-то. 🙂 Особенно сейчас.

            Однако предложение: “Ну зачем вам вот это вот, оно для вас сейчас совершенно ни к чему, вы его просто не сможете использовать в полной мере, а стоит оно тут ого-го, возьмите вот так вот, и все будет работать точно также” воспринимают не менее чем как оскорбление. “Как! Мы биг энтерпрайз (ну по крайней мере хотим ими быть), а вы нам какой-то едва ли не entry level подсовываете!”

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

            Предполагается использовать для этого Symantec NetBackup.

            Ну тут, в принципе, все просто: один NBU Server, два NBU Client for UNIX и лицензия на Tape Library, 1 Drive.

            Затык один: клиент хочет “чтобы бэкап шел по SAN”, чтоб все “как у больших”.

            Ну, если “как у больших”, то тогда нужны уже версии Enterprise для сервера и клиентов, только в них есть SAN Backup и SAN Client.

            А это совсем другие деньги, тоже как для “больших”.

            Итого, в рекомендованных ценах от Symantec – более 39 тысяч долларов для всего двух серверов!

            И каждый следующий подключенный сервер обойдется как минимум в 15 тысяч!

            И это только за нашу прихоть “бэкапить по SAN” и больше ни за что (больше никакие другие функции Enterprise Client/Server использовать не планируется).

            Но если мы не боимся, что нас “пацаны засмеют”, и воспользуемся стандартным бэкапом по сети (а ведь для бэкапа по сети, если уж мы ни в какую не хотим бэкапный трафик пустить в общую LAN, мы запросто можем поставить выделенный гигабитный сетевой адаптер), то нам будет достаточно версий Standard, и, для того же самого, всего около 14 тысячплюс 1700$ за каждого дополнительного клиента).

            А если мы еще чуть внимательнее отнесемся к экономии денег, и тщательнее посмотрим на прайс Симантека то обнаружим там такую чудесную вещь, как NetBackup Starter Kit, в который входит “NBU Server for UNIX Tier 2 + Tape Library License + 5 NBU Clients”, то есть все то что нам надо, плюс еще три клиента на будущее, в запас, и за все про все – 6000 долларов!

            Итак, за каприз клиента “хотим как у взрослых” он заплатит, причем без малейшей реальной эффективности и выгоды для своей IT-функциональности, в шесть с половиной раз больше!

            Это ли не красноречивый пример IT-расточительности?

            Romx

            http://blog.aboutnetapp.ru/

          • Главная Storages, Новое Storages, мысли
            • О сбалансированности

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

              «Перелет» – система «навырост»

              Достаточно распространенный случай несбалансированной системы это покупка системы «навырост», под дальнюю перспективу, неоправданную на сегодняшний день, либо с переоценкой потребностей. Немалую роль в этом играют и сами системные интеграторы, которые всегда рады «исполнить любой каприз заказчика за его деньги», и, разумеется, поощряющие его на такие дорогостоящие капризы. Чаще всего они пользуются как неадекватной оценкой потребностей клиента (например, отсутствием или неверно выполненным анализом необходимой производительности информационной системы, частью которой становится система хранения, завышением требований), либо путаницей, зачастую преднамеренной, созданной многочисленными маркетинговыми обещаниями.

              «Мы не хотим покупать систему с 2GB FC портами, ведь уже есть 4GB порты, а они вдвое быстрее!».
              «Нам нужна система хранения с самыми быстрыми дисками, на 15K. Ведь когда у нас стояли в сервере два диска SCSI на 10K, все было очень медленно».
              «Мы хотим библиотеку на дисках BluRay, потому что это самая новейшая технология. Библиотеки на магнитных лентах давно устарели!»

              В защиту такого поведения системных интеграторов следует сказать, что зачастую процесс апгрейда имеющейся системы хранения для оборудования большинства вендоров-создателей систем хранения зачастую сопряжен с серьезными временными и денежными затратами (приятным исключением являются системы Network Appliance). Затраты настолько велики, что зачастую выгоднее становится, при малейшем подозрении на перспективы значительного роста (и зачастую невозможности провести адекватный «сайзинг»), потратить сегодня больше, с тем чтобы отодвинуть время необходимости смены системы хранения как можно дальше в будущее, а в идеале передать этот хлопотный и мучительный процесс следующему IT-менеджеру 😉

              «Недолет» – всюду жмет

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

              «Давайте купим самую дешевую систему, ведь главное, чтобы на нее поместилась наша база данных!»
              «Может быть просто купить 6 дисков SATA для нашего сервера, и этого будет достаточно?»
              «Мне выделили 3 тысячи долларов на покупку системы хранения, надо купить что-нибудь крутое за эти деньги. Например терабайта на два-три».

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

              Несбалансированная система – «перекосы»

              Обычно это частный случай рассмотренного выше, сочетание первого и второго, когда в системе что-то одно «жмет», а что-то другое «навырост».

              4GB FC ports и диски SATA
              Диски 15Krpm на системе для резервного копирования данных.
              Восьмипроцессорный сервер под 1С:Предприятием 7.7

              При несбалансированности решения вполне можно потратить бездну денег и получить 5% прирост производительности. Хороший пример – недорогая система хранения начального уровня, наполненная дисками 15K. По сравнению с дисками 10K цена вырастает минимум на треть, однако вовсе не факт, что на недорогой системе хранения производительность вырастет в полтора раза, как это могло бы быть на более мощной системе с большим кэшем и более мощным процессоро
              м обработки. Просто возникает эффект «бутылочного горлышка»: как ни дави, сколько ни трать денег, все равно больше, чем просочится через самое узкое место, из системы не выжать. Происходит эффект мотора от Феррари на Жигулях. Много дыму, рева, расхода высококачественного бензина, однако реальная скорость передвижения практически не увеличилась.

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

              «Недодумали» или «переоценили»

              Достаточно часто встречаются в жизни даже не столько «системные» перекосы, такие как рассмотренные выше, а мелкие, локальные, но имеющие не менее губительные последствия. Наиболее часто встречается несовместимость проданного оборудования и программного обеспечения или разного оборудования между собой.
              В случае «многовендорного» интеграционного проекта, с множеством участников со стороны производителей оборудования и ПО, «матрица совместимости» проекта может расти в геометрической прогрессии. Учесть всю возможную специфику взаимодействия программных и аппаратных компонентов, взаимодействующих «каждый с каждым», бывает достаточно непросто.
              В рассмотренном случае вина за проблемы ложится целиком на системного интегратора.
              Однако зачастую проект начинает перекраиваться по требованию заказчика. Во множестве случаев у интегратора не оказывается достаточно «рычагов» и сил, чтобы воспрепятстсвовать такому вмешательству “специалистов, которые платят деньги и заказывают музыку”.

              Пример из жизни
              Крупный химический завод хочет создать отказоустойчивую систему управления производством, использующую базу данных Oracle. Для этого создается кластер на базе Veritas Cluster Server из двух серверов SUN, приобретается common storage EMC CLARiiON CX, к которому по FC подключаются два сервера SUN Fire V. Казалось бы, все хорошо: в случае выхода из строя одного из серверов, с помощью служб VCS задача системы управления производством, представляющая собой БД Oracle и написанные вокруг нее приложения, рестартует на резервном сервере. Однако в какой-то момент из спецификации «в целях экономии IT-бюджета» вычеркивается Veritas Storage Foundation с журналируемой файловой системой VxFS для Solaris. И все устанавливается на обычный UFS.

              И теперь в случае выхода из строя первичного сервера, резервный запускается, монтирует на себя common storage на EMC CLARiiON, и… запускает fschk.
              На 20 минут.

              «“Немного недодумали” чаще всего означает, что не думали вообще».

              Romx

              http://blog.aboutnetapp.ru/