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


Читать дальше →

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

Что касается сайтов, то их классифицировать можно по-разному. И для каждой тематике нужно применять свои правила и законы. Однако, есть ряд моментов, которые подходят сайтам всех разновидностей.


Читать дальше →

Недавно Facebook анонсировал свое соревнование по прогрммированию: Hacker Cup. Я ждал, что статья о нем на хабре появится сразу, но нет, поиск по такому запросу возвращает пустой результат.

Тогда я сделал поиск по запросу TopCoder Open и Google Code Jam, и, как и ожидалось, увидел только несколько статей с результатами соревнований. Значит надо заполнить эту нишу и написать статью о том, что же такое соревнования по программированию, с чем их едят, и как ты, дорогой хаброюзер, можешь в них поучаствовать, и что тебе это даст.

Я расскажу исключительно о так называемом «спортивном» программировании.

Читать дальше →

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

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

Польза от регистрации компании именно на Кипре — Евросоюз, с 2009 года Кипр исключен из списка оффшоров ЦБ РФ, низкий процент налога на прибыль по Европе.

Читать дальше →

Вводная

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

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

Собственно созерцание этих алгоритмов навело меня на мысль о возможности перестановки строковых (символьных) значений.
Читать дальше →

Наверно каждый задумывался сколько будет 356+452? На решение этого задания в среднем уходит до 3^ех минут.

Многие школьники (8+ классов) не умеют находить корни уравнения x²-7x+10=0 (в уме), я уже не говорю о 2x²-14x+20=0. Как решить эту проблему с минимальными затратими? Все очень просто: компьютер мне в руки!


Читать дальше →

Рассказ о том, как мне захотелось написать простенький интерфейс под андроид и сколько неожиданных препятствий мне пришлось преодолеть. Акцент здесь сделан не на слове “препятствий”, а слове “неожиданных”.

Но обо всём по порядку.

Решил я начать с GUI. Имея за плечами изрядный опыт работы с Java и GUI (очень разными — от MFC до Qt — но, как выяснилось, такими одинаковыми) понаделся прорваться на халяву. В качестве усложняющего фактора решил навесить немного анимации на кнопки.

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


Сразу же нашёл в (так называемой) документации масштабирование. Но оно работает с видами (view – именно так называются все окна и контролы в андроиде), как с картинками. Не годится — расширяются также границы кнопки — выглядит убого.

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

Начинаю расставлять кусочки картинки по нужным местам. LinearLayout как раз для такого случая – собираются сначала горизонтальные строки – затем складываются друг на друга. Порядок определить просто, а размер задаётся через setWidth() и setHeight(). А вот нет – эти функции несмотря на всю очевидность не работают ни разу. Что на это говорит документация? – Должны работать (пруф ). Начинаем копать почему. Логика работы layout довольно хитрая. Работает всё в несколько заходов с вызовом protected функций, которые необходимо переопределить… Если короче, то правильный ответ –это магия — надо использовать setLayoutParams(new LinearLayout.LayoutParams(width, height)). Зато логика работы layout проявляется в том, что в момент создания высота и ширина не известны. Поэтому попытка растянуть картинку при инициализации обречена – новая ширина и высота зависит от старой. Короче – ждём onWindowFocusChanged() и в нём устанавливаем размер.

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

Итак – родная анимация умеет масштабировать и двигать. Нам большего не нужно. (А ведь был соблазн обойтись только масштабированием — остальные кнопки должны естественным образом сдвигаться. Но нет — при масштабировании контейнер не изменяет размер. Приходится двигать и внимательно следить за взаимным положением всех объектов на экране). Средние части масштабируются, нижние или верхние двигаются. Как синхронизировать анимацию? Очевидно. Задать одинаковое время старта. Результат тоже очевиден. Задать в точности один и тот же объект анимации всем окнам. Результат тот же. Правильный ответ (с точностью до видимых эффектов на конкретном телефоне) – задавать разные, но с одинаковыми параметрами, объекты анимации для всех частей. Почему? Магия. (Кстати – clone() для создания таких одинаковых объектов существует, но он protected – видимо, из вредности).

Кульминация. Необходимо сделать что-нибудь вроде нескольких последовательных анимаций (расширить / сжать). Варианта два:

• Отменить анимацию с одновременным изменением размеров частей. Следующую анимацию применять к «чистому» (неискаженному объекту). Считается, что так правильно (Кем считается? Официальной документацией).
• Не отменять анимацию, а придумывать следующую с учётом текущего искажения объекта.

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

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

Короче: ищем третий вариант. Его нет – используем первый. Испробовал N-е количество способов — всех и не упомнишь — ничего не помогает. После танца с бубном получается приемлемый вариант (почти без миганий) путём изменения порядка расположения окон (окно, которое меньше всех склонно к миганию отрисовывается сверху).

Последний штрих. Отрисовка текста на кнопке. В тексте главное – граница — а точнее, чтобы он не рисовался за границей кнопки. Кладём на нашу кнопку еще один вид. Забиваем на масштабирование картинки. Тут почему-то трудностей не оказалось — canvas.getMatrix().getValues(m)[4] = 1.0 в onDraw() (если кто программировал одновременно 6 систем координат сразу пойдёт, что здесь изменять нужно именно 4 элемент матрицы — кто не программировал — может попробовать все варианты — их всего 9) и в том же onDraw() рисуем текст. Границы текста определяются границами вида, который масштабируется – всё хорошо (Внимательный читатель и тут наверняка заметил магию — границы кнопки меняются, а границы LinearLayout — нет). Только чуть чуть мигает. Всякие жалкие попытки исправить мигание (например, путём скрывания трансформированной надписи с одновременным отображением другого вида, выглядящего точно также) обречены. Мигает. Но не сильно – на быстрых устройствах практически не заметно.

Оргвыводы. Писать под андроид – весьма увлекательное занятие. По пунктам:

• Качество документации. Оно отвратительно. Большинство функций задокументированы путём расстановки пробелов в названии функций (пруф). При чтении некоторых в голову почему-то приходят слова “надмозг” и “расовый индийский” (пруф). Ну а в некоторых случаях документация вообще отсутствует. В качестве упражнения повышенной сложности попробуйте в runtime (не через XML) создать ProgressBar в виде полоски, а не кругляшка.
• Сообщество гораздо слабее, чем в других областях (я имею ввиду как минимум Java, C/C++ и Ruby). Пишущих под андроид физически гораздо меньше. На многие вопросы ответа в интернете просто нет.
• Сильно нестандартная логика работы. Для людей, выросших на MFC/VCL/Qt/wxWidgets/WinForms/AWT/итд этот опыт почти не пригождается – здесь многое по другому. Постоянно приходится преодолевать неожиданные препятствия. Наверняка гугль придумал свою систему гораздо лучше, чем люди до него, но моим мозгам, испорченным всем выше перечисленным, пришлось трудновато приобщаться к прекрасному.
• Совет «спроси у гугля» выглядит попросту издевательством.

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

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

Для начала некоторое лирическое отступление. Для американского рынка существует великое множество подобных приборов, например серия «Kill-A-Watt». Киловатт и Kill-A-Watt это игра слов, которая явно намекает на то, что основная цель приборов это уменьшение расхода электроэнергии. Есть приборы для индивидуального использования, есть монстры, которые включает несколько беспроводных датчиков и дисплей, на котором вы можете в любой момент посмотреть, что сейчас работает и сколько набежало и сравнить с показанием главного счетчика. Утверждается, что пользование этим прибором учит более экономичному использованию электроприборами. Для европейского рынка я не сразу нашел подходящий прибор для сети 220вольт, но в конце у одного китайца на eBay он был найден и приобретен за 20 долларов включая доставку.



Что может прибор? Во первых он показывает полную потребляемую мощность устройства. Также он имеет функцию счетчика и показывает общий расход электричества. Если вы введете стоимость киловатта, то сразу сможете увидеть расход в денежном эквиваленте. Есть возможность выставить верхний порог потребляемого электричества, и если по какой либо причине расход превысит этот уровень, то прибор оповестит вас об этом. Также прибор измеряет напряжение сети.
Теперь о некоторых размышлениях по результатам замеров. Многие люди используют старый компьютер в качестве сервера для торрентов, и других P2P сетей. Этот компьютер обычно включен в сеть 24 часа 365 дней в году. Средняя потребляемая мощность этого компьютера 100 ватт (только системного блока). Компьютер Q6600+8gb RAM+2HDD показывал потребляемую мощность около 120 ватт, поэтому я немного округлил для удобства расчетов и ввиду того, что этот компьютер еще тяжело назвать – старый. Итого 100ватт X 24часа X 365дней = 876киловатт. По Израильским ценам на электричество это почти 120 долларов в год. Какие есть альтернативы? Например, приобрести ноутбук 5-6 летней давности. К примеру, мой IBM R40 512mb 1.4Centrino потребляет 15ватт с закрытым монитором. 15ватт X 24часа X 365дней = 131.4киловатт. 744 киловатта разницы или где-то 100 долларов в год, а если за 5 лет, 10 лет? Получаются уже довольно приличные суммы и как бы из ничего. Кроме того ноутбук занимает гораздо меньше места, и не шумит.

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

Я не буду вас утомлять примером с дешевым радиатором, который потребляет 1500ватт, и дорогим радиатором, который делает одинаковую работу, но за 1000ватт и за сколько времени покупка более дорого радиатора окупиться или наоборот более дешевого станет нерентабельной. Хочу только затронуть еще одну ситуацию когда этот прибор может быть полезен. В нем можно установить коэффициент израсходованной электроэнергии к проработанному времени и в случае если он будет превышен, то прибор вас известит об этом. Например, если в холодильнике или в кондиционере начнет утекать газ, то между временем пока это случилось, и он перестанет полностью работать, может пройти не один месяц. Заметить эту утечку практически невозможно, ведь холодильник будет морозить, а кондиционер обогревать\охлаждать, но они будут затрачивать на это гораздо больше электричества.

Кстати, кондиционер я себе так и не купил, так как оказалось не рентабельно.

Все знакомы с такими проблемами, как внезапное отключение энергии, вирусы, уничтожающие самое ценное, рассыпающиеся носители на жёстких дисках, кражи, которые в итоге зачастую выливаются в потери данных. Да, для всего этого есть частные решения, такие как UPS, антивирусы, надёжные операционные системы, системы резервирования на магнитных лентах, S.M.A.R.T, милиция, замок Кенсингтона и т.п., которые тоже нередко подводят, а ко всему прочему отключают бдительность.

Давайте послушаем, что об этом говорят гуру. Только гашноты делают резервные копии на ленточных накопителях. Настоящие пацаны выкладывают всё важное на FTP. А ведь сообщению-то уже почти 15 лет, неужели с тех самых пор практически ничего не изменилось? Вроде бы уже скорость скачивания данных через торренты вплотную подобралась к скорости чтения с жёсткого диска, а стоимость хранения данных на удалённом сервере соизмерима со стоимостью жёсткого диска аналогичного объёма, поделенную на период его морального устаревания.

Что будет дальше? Неужели никто так ничего и не придумал, чтобы спасити наше всё — данные от пропажи? Как спасити данные, застраховаться от всех негативных локальных последствий?

Сейчас

Самое важное

Многие знают, и все слышали о таких сервисах для хранения самого ценного, того, что хватают, выбегая из дома при пожарах (нет, не компьютерщики, с ними понятно) — фотографий: Picasa и Flickr.

Музыка и фильмы

Уже многие составляют свою музыкальную коллекцию Vkontakte. Многие смотрят кино онлайн. Реже — легально, ведь Hulu, Pandora и подобные до нас пока ещё, к сожалению, не добрались.

Игры

Любителям простых игр доступны игры Flash и HTML5/SVG.
Некоторой части населения Земли повезло, и они могут затестировать сервис полноценных игр по запросу OnLive.

Ладно, а что с более полезными вещами?

Редактирование фото и графики

Пожалуйста, Pixlr.

Документы, таблицы и другая офисная мишура

Google Docs, Zoho Office, MS Office Live.

Хранение всего подряд

Dropbox

Липучие бумажки и пространные записи

Evernote, Remember the Milk

Почта

Думаю, тех, кто пользуется Outlook'ом остаётся с каждым днём всё меньше.

Мнгновенные сообщения

Meebo, IMO, GTalk

Печать фотографий дома

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

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

Страшно доверять данные «дяде»?

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

Страшно регулярно передавать данные по сети?

Используйте защищённый протокол HTTPS.

Разработчики, разработчики, разработчики, разработчики

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

Вот, возьмём свеженькую машинку от Google Cr-48 с установленной операционной системой Google Chrome OS, единственным приложением запускающимся на которой является также предустановленный, как вы уже догадались, браузер Google Chrome.

Хорошо, браузер уже есть. К огромному сожалению нет поддержки режима отображения IE6.

Приладим замечательный редактор исходного кода, который сам себе и браузерный клиент и серверный сервер, Bespin/Skywriter к своему любимому удалённому серверу, либо воспользоваться чужим сервисом так, как сейчас мы пользуемся VS, Eclipse'ом и прочими замечательными. Просто меняем толстого клиента на [вставить язык, на котором он написан] на «тонкого» на JavaScript'е. Разницы — никакой, он точно так же ищет по проекту, работает с контролем версий. Только что можно в любой момент накрыть вас ядерной бомбой, а ваш код будет жить вечно. Если только ядерной бомбой не накроет датацентр.

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

За виртуальными машинами в таком и без того виртуализированном окружении дело не встанет.

Так что, пока есть немного времени, переползаем в сеть ещё глубже.
И, запасшись попкорном, смотрим в будущее.

Тестовая среда:
В качестве тестовой площадки выступало следущее оборудование:
2 компьютера с идентичной конфигурацией (CPU 3.0Ghz, RAM 6Gb, HDD 160Gb, 1 LAN OnBoard, 1PCI-E External LAN 4 port)
Сетевое оборудование CISCO Catalyst 2960S и CISCO Catalyst 3560G

Продолжительность тестирования:
Продолжительность тестирования составило 18 рабочих дней.

Тестирование
Тестирование проводилось в 3 этапа: Linux – Linux, Linux – Windows, openSolaris – Windows.

Режимы работы NicTeaming (Bonding):
0 — balance-rr При передачи данных меняет интерфейсы поочередно(Round-robin).
1 — active-backup Один из интерфейсов активен. Если активный интерфейс выходит из строя, другой интерфейс присваивает MAC-адрес и становится активным. Данный режим предоставляет только отказоустойчивость и не требует специальной поддержки со стороны коммутатора.
2 — balance-xor Передачи распределяются между интерфейсами на основе формулы ((MAC-адрес источника) XOR (MAC-адрес получателя)) % число интерфейсов. Один и тот же интерфейс работает с определённым получателем. Режим даёт балансировку нагрузки и отказоустойчивость.
3 — broadcast Передаёт все пакеты на все интерфейсы объединения, обеспечивая повышения отказоустойчивости.
4 — 802.3ad Это классический IEEE 802.3ad, динамическое объединение каналов. Требует поддержки 802.3ad от коммутатора и восстановления скорости и дуплекса от драйвера каждого из интерфейсов.
5 — balance-tlb Адаптивная балансировка нагрузки передачи. Входящий трафик получается только активным интерфейсом, исходящий же распределяется в зависимости от текущей загрузки каждого интерфейса. Не требует специальной поддержки коммутатора.
6 — balance-alb Адаптивная балансировка нагрузки — обеспечивает балансировку нагрузки как передачи (TLB, transmit load balancing), так и приёма для IPv4 через ARP. Не требует специальной поддержки коммутатором, но требует возможности изменять MAC-адрес устройства.

Результаты тестирования Linux – Linux.
В качестве Операционной Системы для тестирования (ОС – сокращение в дальнейшем) был выбран дистрибутив Debian Linux Lenny stable x64.
Для установки драйверов понадобилось дополнительно установить ряд пакетов: net-tools, ethtool, ifenslave-2.6, build-essential, make.

Затем создаем bonding (он же NicTeaming), для этого создаем сетевой интерфейс bond0 который будет объединять в себе 4 интерфейса, eth1, eth2, eth3, eth4. Для этого правим файл /etc/network/interfaces

auto bond0
iface bond0 inet static
 address 10.10.250.2
 netmask 255.255.255.0
 network 10.10.250.0
 bond_mode balance-rr
 bond_miimon 100
 bond_downdelay 200
 bond_updelay 200
 slaves eth1 eth2 eth3 eth4

Таким же способом на 2 компьютере создан интерфейс с IP: 10.10.250.3.

Сделали сервером компьютер с IP 10.10.250.2. Здесь и в дальнейшем условимся, что сервер – это ПК с IP адресом 10.10.250.2, а клиент – это ПК с IP адресом 10.10.250.3.

Так как мы решили тестировать по протоколу iSCSI и не ограничивать себя в скорости работы с жетскими дисками, мы будем использовать RAMDrive.
Для этого создадим на сервере RAMDrive в котором развернем iSCSI ресурс.

mount -t tmpfs -o size=3000M tmpfs /mnt/tmpfs/ 

-так мы выделили оперативную память
затем устанавливаем iSCSI-Target

sudo apt-get install iscsi-target

После этого настраиваем iSCSI путем редактирования его конфигурационного файла /etc/iet/iet.conf

Target test.802:test-debian.lun0
 IncomingUser
 OutgoingUser
 Lun 0 Path=/mnt/tmpfs/image.img,Type=fileio
 Alias LUN0
 MaxConnections 1

И создаем само iSCSI хранилище размером 2.1Гб в RAMDriv’e емкостью 3Гб.

dd if=/dev/zero of=/mnt/tmpfs/image.img bs=1024k count=2000

После чего перезапускаем службу iSCSI и службу сетевых интерфейсов

/etc/init.d/networks restart
/etc/init.d/iscsi-target restart

После чего проверяем NicTeaming(bonding) выполнив команду:

cat /proc/net/bonding/bond0

Ethernet Channel Bonding Driver: v3.2.5 (March 21, 2008)
Bonding Mode: load balancing (round-robin)
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 200
Down Delay (ms): 200

На клиенте был установлен пакет open-iscsi и перезапущены сервисы сетевых интерфейсов и iSCSI-Initiator, после чего выполнили команду

iscsiadm -m node --targetname test.802:test-debian.lun0" --portal "10.10.250.2:3260" –login 

и подключили хранилище iSCSI.

Затем мы подключили iSCSI хранилище и RAMDrive выполнив

mount -t tmpfs -o size=3000M tmpfs /mnt/RAMDrive/

mount –t auto /dev/sdb1 /mnt/iSCSI/ 

— /dev/sdb1 – это сетевое iSCSI хранилище, посмотреть новый диск в системе можно с помощью fdisk –l после выполнения команды iscsiadm описаной выше.

Наиболее оптимльном режимом работы оказался balance-rr, вот его результаты:

Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 185-310MB/Sec
RAMDrive -> iSCSI 135-185MB/Sec

Перезапись файла:
iSCSi -> RAMDrive 180-320MB/Sec
RAMDrive -> iSCSI 150-175MB/Sec

Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.

PING
# ping -s 65000 10.10.250.2
PING 10.10.250.2 (10.10.250.2) 65000(65028) bytes of data.
65008 bytes from 10.10.250.2: icmp_seq=503 ttl=128 time=1.34 ms
65008 bytes from 10.10.250.2: icmp_seq=504 ttl=128 time=1.31 ms
65008 bytes from 10.10.250.2: icmp_seq=505 ttl=128 time=1.32 ms
65008 bytes from 10.10.250.2: icmp_seq=506 ttl=128 time=1.34 ms
^C
— 10.10.250.2 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 507016ms

Ресурсы обоих систем Debian Linux были вполне свободны:
SWAP – 4Gb использовался 1-3%
RAM – 6Gb, из них 3Gb отведено под виртуальный диск, свободно всегда оставалось 600-800Mb.
Загрузка процессора составляла 7-30%
Загрузка сети 18-27%

Как видно из результатов, скорость передачи данных не синхронна и очень мала для заявленого 500-650М/сек по описанию технологии с применением NicTeaming’а на 4-х портах сетевого адаптера. В режиме наибольшей прорускной способности (802.3ad) оборудование CISCO зависло 2 раза.

Попытка использовать протокол NFS дала прирост в скорости чтения на 10-15%, но на столько же снизило скорость записи.

Результаты тестирования Linux – Windows
В качестве ОC сервера остался Debian Linux Lenny stable, в качестве клиентской ОС был установлен MS Windows 2003 Server Standard R2.
На клиенте был установлен RAMDrive и Microsoft iSCSI Initiator, а так же создан NicTeaming (Bonding) в режиме 4 ( 802.3ad) – так как именно в этом режиме работы были достигнуты максимальные показатели. Так же был отключен IPS и QoS, как в настройках подключения, так и через GPU (Груповая политика — mmc).
Никаких других настроек над системой не проводилось.

Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 63-70MB/Sec
RAMDrive -> iSCSI 365-400MB/Sec

Перезапись файла:
iSCSi -> RAMDrive 40-60MB/Sec
RAMDrive -> iSCSI 340-380MB/Sec

Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.

Так же были проведены тесты с помощью утилиты sqlio.

Результаты команды ping от сервера до клиента

PING
# ping -s 65000 10.10.250.3
PING 10.10.250.3 (10.10.250.3) 65000(65028) bytes of data.
65008 bytes from 10.10.250.3: icmp_seq=503 ttl=128 time=1.24 ms
65008 bytes from 10.10.250.3: icmp_seq=504 ttl=128 time=1.21 ms
65008 bytes from 10.10.250.3: icmp_seq=505 ttl=128 time=1.24 ms
65008 bytes from 10.10.250.3: icmp_seq=506 ttl=128 time=1.12 ms
^C
— 10.10.250.3 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 507003ms

Загрузка сети не поднималась больше 23%, средняя загрузка процессора составляла 48-72% на каждое ядро.

Как видно скорость передачи данных снова не синхронна и очень мала для заявленой технологии, но тем не менее скорость записи на хранилище (iSCSI) была намного выше чем между двумя одинаковыми ОС на базе Debian Linux, в результате чего далее будет проведен тест между клиентом с ОС Windows 2003 Server и серевером с предустановленой ОС openSolaris.

Результаты тестирования openSolaris – Windows
В качестве ОC сервера был установлен дистрибутив ОС UNIX (openSolaris), в качестве клиентской ОС осталась установленная ранее MS Windows 2003 Server Standard R2.

Для начала на сервере настроим Link Agregation 802.3ad, т.к openSolaris может работать только в этом режиме NicTeaming’а.

Сначала проверим доступные сетевые интерфейсы, для этого выполним

dladm show-link

.
Далее мы отключаем все интерфейсы которые будем использовать при создании NicTeaming’а, создадим сам NicTeaming и поднимем интерфейс с NicTeamimg’ом обратно, для этого выполняем следующие действия:

pfexec ifconfig igb0 unplumb # Выключаем интерфейсы igb0 – igb3 
pfexec ifconfig igb1 unplumb
pfexec ifconfig igb2 unplumb
pfexec ifconfig igb3 unplumb

pfexec dladm create-aggr -l igb0 -l igb1 -l igb2 -l igb3 aggr01

# Создаем NicTeaming в режиме 802.3ad

pfexec ifconfig aggr01 plumb 10.10.250.2 netmask 255.255.255.0 up

# Поднимаем настроеный интерфейс NicTeaming’a aggr01 и задаем ему IP и маску подсети.

Затем создадим RAMDrive объемом в 1.1Гб в который поместим наше iSCSI хранилище и создадим там файловую систему, для этого выполним следущее:

ramdiskadm -a ram1 1200m
zpool create rampool1 /dev/ramdisk/ram1

zfs list rampool1 

# Проверим новый пул созданный из RAM.

Теперь создадим iSCSI-Tagreg, для этого необходимо доставить 2 пакета в систему:

pfexec pkg install SUNWiscsit
pfexec pkg install storage-server

Настраиваем ZFS iSCSI Volume на сервере Target

# zfs create rampool1/iscsiram1

— создаем файловую систему, где будет находиться наш том

Далее необходимо запустить и настроить службу iSCSI-Target, для этого делаем следущее

# svcadm enable iscsitgt — запускаем службу iscsitgt
# svcs iscsitgt
STATE STIME FMRI
online 10:25:18 svc:/system/iscsitgt:default

# zfs create -b 128k -V 1100m rampool1/iscsiram1

— создали том zfs на 1.1Гб

Главное здесь что поставлен размер блока 128б, если будет меньше – то это будет сказывается на производительности

# zfs set shareiscsi=on rampool1/iscsiram1 

— добавили в настройки тома

# iscsitadm create target -b /dev/zvol/rdsk/rampool1/iscsiram1 openSolaris-ISCSI-Target

— создаем target iscsi для нашего пула

# iscsitadm list target -v

— проверяем создание таргета, отсюда берем инфу для конфигурации сервера – initiator

Target: openSolaris-ISCSI-Target
iSCSI Name: iqn.opensolaris.open.ru:02:dcd36c1f-2572-6dc5-d6b0-b5522c4daf56.openSolaris-ISCSI-Target Connections: 0
ACL list:
TPGT list:
LUN information:
LUN: 0
GUID: 0
VID: SUN
PID: SOLARIS
Type: disk
Size: 1.1G
Backing store: /dev/zvol/rdsk/rampool1/iscsiram1
Status: online

Ну вот мы имеем настроеный iSCSI-Target с NicTeaming в режиме 802.3ad.

Тестирования проводились в 2-х вариантах, 1-ый с включенным и настроеным CISCO и настроеными интерфейсами клиента и сервера на LACP и PagP, 2-ой в автоматическом режиме настройки.

Скорость работы с файлами:
Копирование:
iSCSI -> RAMDrive 80-120MB/Sec
RAMDrive -> iSCSI 350-400MB/Sec

Перезапись файла:
iSCSi -> RAMDrive 80-90MB/Sec
RAMDrive -> iSCSI 350-400MB/Sec

Где iSCSI – область памяти в RAMDrive на сервере, а RAMDRive – область памяти на клиенте.

Так же были проведены тесты с помощью утилиты sqlio.

Результаты команды ping от сервера до клиента

PING
# ping -s 65000 10.10.250.3
PING 10.10.250.3 (10.10.250.3) 65000(65028) bytes of data.
65008 bytes from 10.10.250.3: icmp_seq=503 ttl=128 time=1.27 ms
65008 bytes from 10.10.250.3: icmp_seq=504 ttl=128 time=1.11 ms
65008 bytes from 10.10.250.3: icmp_seq=505 ttl=128 time=1.12 ms
65008 bytes from 10.10.250.3: icmp_seq=506 ttl=128 time=1.17 ms
^C
— 10.10.250.3 ping statistics — 506 packets transmitted, 505 received, 0% packet loss, time 506021ms

Во время работы с ненастроеной CISCO на LACP и PagP, оборудование CISCO 2-ы повисло. После повторного включения CISCO скорость передачи данных была синхронна, и на протяжении 6 минут была равно 350МВ/сек в каждую сторону. После чего снова началась рассинхронизация скорости передачи данных.

Повторить результат или понять причину не удалось.

Общее заключение
Добиться синхронных результатов скорости передачи данных хотя бы в 250-350MB/сек, так и не удалось не смотря на описание технологии где сказано что этого можно добиться. В различных условиях тестирования скорость отличалась не сильно, хотя при работе в связке openSolaris и Windows 2003 был почти достигнут желаемый результат, но повторить его так и не удалось. Возможно если повторить эксперимент позже с более новыми драйверами и другим оборудованием – результаты будут другие, но на данный момент достичь желаемого сейчас нам не удалось, возможно нужно более тщательно подбирать используемое оборудование для обеспечения лучшей совместимости. При отказе одного из интерфейсов (физическое выключение кабеля из CISCO) потери были минимальны, данные передавались сразу же на другой интерфейс. Поэтому данную технологию можно использовать для повышения отказоустойчивости работы сети.