27 March 2009

Кризата, технологиите и пазара

Спряха ли клиентите да купуват?

Едва ли остана някой, който да не чул поне за „кризата”. Повечето са разбрали, а има и доста компетентни по темата, същите, които преди няколко месеца обяснаваха на висок глас, че такова нещо няма.

Е, вече всички са убедени, че тя е налице. Дори сме по средата й... на глобалната икономическа криза, някъде около фундаменталната крива круша. Фондовия пазар се огъва, някои компании са на прага на несъстоятелността, хората губят работните си места и правителства се опитват да спасят местните икономики. Да, очертава се сериозен проблем за страните, компаниите и хората! Но с всеки проблем изниква нужда от неговото решаване. Нима това не са възможности?


Светлия лъч в тунела е възможността за новите технологии. Кризата ги прави нужни и това е техния шанс за усъвършенстване и приемане от потребителите. Очевидно е, че технологията не може да реши всеки проблем, но когато го има се търси решение или ресурс за решаване. Нека погледнем компютъра. Разработен в ужасните времена на Втората световна война да помогне с изчисляването на артилерийски данни и криптирани кодове. Компютрите не прекратиха войната, но спокойно може да се твърди, че те са помогнали за по-близкия й край. А сега, когато компютрите са навсякъде, те решават задачи много по-многобройни и сложни от артилерийски данни или шифри.


Нека погледнем настоящето - разполагаме с текущите глобални икономически проблеми. Смятам, че новите технологии могат да печелят не една и две битки във войната със световната рецесия.

Напоследък много технологични компании отчитат лоши тримесечни финансови резултати, защото продават технологиите във вид на продукт. За разлика от тях, компаниите фокусирани в доставянето на услуги продължават да се развиват добре. Това е така, поради решението на клиентите да не придобиват технологията, а да я ползват като услуги от външен източник. При този подход се редуцират разходите за първоначално придобиване при неотменената възможност да се възползват от новите технологии. Допълнителния бонус са значителни спестения при оперативните разходи.

Очевидно е, че клиентите продължават да харчат, но все по-малко за продукти и все повече за услуги. Следователно, няма криза в ИТ бранша! Има преразпределяне на пазарните потребности и разходите.

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

Какво правят големите?

След много шум сред ИТ средите, а след това и в медиите на общественото внимание бе представена концепцията за "изчислителни облаци” (Cloud Computing). В началото доста размита, идеята започна постепенно да придобива своя облик. Облечена в дрехите на бизнес ефекта, беше само въпрос на време преди големите играчи, като IBM да предложат реална услуга. Само припомням, че много от продуктите вече носят логото Lenovo.

Кой е Ерик Клементи?

Преди месец, IBM го назначи за ръководител на направлението Big Blue Cloud Computing. Неговото назначаване е официалния старт на начинание подготвяно от месеци. Първите клиенти - Elizabeth Arden, Nexxera, и Голф Асоциацията на САЩ имат намерение да тестват в Big Blue облака, приложенията за собствения си бизнес.

Клементи е на незавидната длъжност генерален директор на корпоративни инициативи. Негова е задачата, потенциалните клиенти да подпишат договор с IBM, а не с конкуренти. През последните 18 месеца, IBM е изградила повече от дузина центрове за данни, обединени в облак, по целия свят. Работата на това звено сега е, да се ускори това усилие, с поглед в бъдещето - приемане на изчисленията в облака, като стандарт за компании и правителства.

С ИТ бюджети под натиск, поради състоянието на икономиката, идеята за изчисления в облака възникна като предпочитано понятие сред обществото поради потенциалните спестявания предлагани на клиентите. Освен предлагането на хардуера, като услуга IBM обяви своя софтуерен пакет Tivoli Storage също като услуга за клиентите на Big Blue Cloud Computing.
Според изследване на IDC, изчисленията в облака ще се развият в пазар за $ 42 млрд. в рамките на следващите три години в световен мащаб.

Днес това е възможност за много стартиращи и малки бизнеси да ползват технологии без да е необходима голямата първоначална инвестиция. В страната ни преобладават малките компании спрямо световните разбирания за размер. Точно тук е шанса за бизнеса в България да използва новите технологии и да бъде конкурентен на по-големите в неговия бранш световния пазар.

Статията е публикувана със заглавие "Криза в IT бранша няма" във вестник "ПАРИ" брой 57(4621)/26.03.2009 година. Поместена е тук с цел достъп до по-широка публика и архив.

25 March 2009

Практически пример за миграция към VMWare ESXi

Преди месец решихме да заменим сървърите обслужващи офиса на наш клиент. След няколко месеца щяха да навършат три години, а натоварването се увеличи поради разрастване на бизнеса и беше наложително да се извърши планирана замяна.

1. Основен сървър: 2xXeon 5140 2x2.33GHz, 4GB памет, 4x73Gb SCSI 15000rpm (RAID 10).

2. Терминален сървър: 2xXeon 5140 2x2.33GHz, 4GB памет, 2x73Gb SCSI 15000rpm (RAID 1)

3. Архивиращ сървър: 1xXeon 3040, 2GB памет, 4х250Gb SATA (RAID5)

Решението бе да ги пренесем във виртуална среда, но клиента предпочете
да тества виртуализацията с безплатната платформа VMWare ESXi (използвахме версия 3.5.0 Update 3). Поради желанието за тест (безплатен), първоначално само мигрирахме текущите операционни системи (в комплект с техните ограничения).
Като цяло сме много доволни от резултата.

Нека видим детайлите:



Хардуер: един сървър с два четириядрени процесора Xeon E5462 2.8GHz, FSB 1600MHz, 16Gb памет, 6х146Gb SAS 15000rpm (RAID 10), 2x1Tb SATA (RAID 1).

Положителни страни:

Производителност

Значително се подобри производителността на системата.
Работейки на един, но много по-мощен сървър, производителността на цялата система е значително по-висока, отколкото при работа върху няколко, но с по-малки възможности сървъри. Работата на терминалните потребители се подобри откъм бързодействие. Средното ниво на натовареност за физически процесор е около 40% - 50% по време на работния ден.

Значително е намалена консумацията на електроенергия

Работата е не толкова в цената на електроенергията (в нашия случай тя не е много), а цената и времето за резервирано захранване на системата. Използвания UPS Ablerex MS3000RT 3000VA с допълнителни батерии. Освен тези сървъри, UPS –а захранва уеб сървър (не сме го включили във виртуалната среда, от съображения за сигурност), офисна телефонна централа PBX, стандартно мрежово оборудване. Автономността на цялата система преди виртуализацията беше 1 час и 08 минути - 1 час и 56 минути в зависимост от натоварването (1 час и 56 минути - през нощта, без натоварване и извън времето за архивиране и системни дейности). Сега времето за автономна работа под товар е 2 часа и 36 минути.

Изчезна зависимостта на операционните системи от оборудването

Всички операционни системи са инсталирани на виртуални машини, чиито конфигурации са стандартни от гледна точка на операционна система и драйвери. Ако се наложи преместване на виртуални машини към нов хардуер, това ще отнеме един порядък време по-малко в сравнение преместване от един физически сървър на друг физически сървър. Само като си спомня последния път, когато го мигрирахме този основен сървър колко време отне и колко нерви... Ние бяхме смазани, клиентите изнервени за неща от типа – не ми се отваря речника, без да подозират, какво се е случило в извънработно време.
Е... сега вече е лесно. Трябва само да се копира файла на виртуалната машина на новия физически хост и... готово! (може и да не щракаме с пръсти)

Лесна миграция на съществуващи сървъри във виртуална среда
Понякога си мисля, че братята по мишка и клавиатура – програмистите се стремят да направят живота на системните администратори – рай. С разни малки на пръв поглед приложения са в състояние да улеснят тежките и времеотнемащи процедури. За съжаление, нищо не е съвършено.
При използване на приложението VMWare Converter се прехвърлят работещи сървъри от физически към виртуални машини. Често процедурата е доста гладка (но не винаги). В конкретния случай, имах само повторно конфигуриране на TCP / IP на мрежовата карта и повторно активиране на Windows Server и Microsoft Office поради значителните промени в хардуерната конфигурация по отношение на OS.

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



Какви проблеми и пречки, срещнахме в хода на работа:

Физически и логически процесори

Windows Server Standard Edition поддържа до 4 процесора. Small Business Server - 2. Проблемът е в това, че когато операционните системи са инсталирани на физическите сървъри, горните ограничения са относно броя на физически инсталираните процесори.
При виртуалните машини - от физическа гледна точка на ОС са процесорите, които VMWare "показва" на гост операционна система - процесорното ядро. Има и ограничение от страна на VMWare ESXi, което не позволява на виртуална машина да отдели повече от 4 процесора (всъщност - процесорни ядра). В резултат на това, когато се инсталира VMWare ESXi на сървър с два процесора QuadCore (общо - 8 ядра), виртуална машина със Standard Edition може да разпредели не повече от 4 процесорни ядра (общо 1-ви физически процесор) и Small Business Server - 2 процесорни ядра.

Не съществуват възможности за включване на устройства към виртуални машини, свързани към портове USB, COM, LPT на физическия хост.
Старите сървъри използваха общо 3 COM (серийни) порта (2 модема и конзола към Juniper). След преместване на сървърите на виртуална среда, трябваше да използваме устройството ATEN SN9108 Serial over the NET, така че да се свърже оборудването, използвано от виртуалните машини.

Налице е софтуер, който позволява достъп през мрежата до USB устройство, свързано с отдалечената машина, но не сме го тествали.

Подобни решения за LPT портове не намерихме.


Изводите:

Очакванията от прехода към виртуална среда се оправдаха напълно. Резултатът е по-продуктивна система, значително по-малко консумирана енергия, респективно по-голям период на аварийно електрозахранване от UPS. В хода на имплементация срещнахме проблеми, но никой от тях не се оказа фундаментален и нерешим.

Преход от физически към виртуални машини може да се извърши с повечето сървъри. В нашия случай, тази миграция е оправдана на 100%.

Статията е публикувана във вестник "ИТ Форум" брой 20/2009 година. Поместена е тук с цел достъп до по-широка публика и архив.

19 March 2009

Juniper SSG140 to IPCop VPN interconnection

В практиката често се налага създаване на VPN тунели между различни рутери/защитни стени. Един случай, с който се сблъсках преди време е site-to-site IPSec VPN между Juniper SSG140 и IPCop 1.4.15. Реших да разпиша една работеща конфигурация, защото не открих нищо в готов вид из интернет пространството и по-конкретно за VPN свързаност към Juniper firewall устройства. „Натъжи” ме и факта, че повечето примери със „заплетени” VPN връзки на IPCop (или линукс базирани firewall-и) са към Cisco и други марки, а с Juniper устройства не се открива много. Но "който търси - намира" и с помощта на "неволята" се стигна до описаната по-долу конфигурация и до една значително по-интересна - когато IPCop е зад NAT, на не какво да е - а на БТК ADSL модем/рутер - ZXDSL832 (ISDN ver.). Този частен случай ще опиша по-подробно в някоя следваща публикация.

Диаграмата:

LAN (10.1.1.0/24) - SSG140 WAN (1.1.1.1) <–> Internet <–> IPCop RED (2.2.2.1) – GREEN (10.2.2.0/24)






SSG140

Untrust zone eth0/0 IP 1.1.1.1
Trust zone eth0/2 IP 10.1.1.1/24





IPCop 1.4.15
RED IP: 2.2.2.1
GREEN: 10.2.2.1/24

Juniper configuration CLI

Phase 1 Config

set ike gateway "IPCOP" address 2.2.2.1 Main outgoing-interface "ethernet0/0" preshare "secret" proposal "pre-g2-3des-md5"

set ike gateway "IPCOP" dpd interval 30

Phase 2 Config
set vpn "IPCOP-VPN" gateway "IPCOP" no-replay tunnel idletime 0 proposal "nopfs-esp-3des-md5"

Policy setup
set policy id 2 from "Trust" to "Untrust" "10.1.1.0/24" "10.2.2.0/24" "ANY" tunnel vpn "IPCOP-VPN" id 2 pair-policy 3

set policy id 3 from "Untrust" to "Trust" "10.2.2.0/24" "10.1.1.0/24" "ANY" tunnel vpn "IPCOP-VPN" id 3 pair-policy 2

IPCop configuration

ipsec.conf
config setup
interfaces="%defaultroute "
klipsdebug="none"
plutodebug="none"
plutoload=%search
plutostart=%search
uniqueids=yes
nat_traversal=no
virtual_private=%v4:10.0.0.0/8,%v4:172.16.0.0/12,%v4:192.168.0.0/16,%v4:!10.2.2.0/255.255.255.0,%v4:!10.1.1.0/255.255.255.0

conn %default
keyingtries=0
disablearrivalcheck=no

conn Juniper #RED
left=2.2.2.1
leftnexthop=%defaultroute
leftsubnet=10.2.2.0/255.255.255.0
right=1.1.1.1
rightsubnet=10.1.1.0/255.255.255.0
rightnexthop=%defaultroute
ike=3des-md5-modp1024
esp=3des-md5
pfsgroup=modp1024
ikelifetime=8h
keylife=1h
dpddelay=30
dpdtimeout=120
dpdaction=restart
pfs=no
authby=secret
auto=start

ipsec.secret.conf
: RSA /var/ipcop/certs/hostkey.pem

2.2.2.1 1.1.1.1 : PSK 'secret'