M-tel VMC Prima комплект - как да ползваме модема K3565-Z със SIM карти от други оператори

.
Преди време взех M-tel VMC Prima комплект за "спешни случаи". В рамките на страната съм го използвал рядко, като няколко пъти наистина ме е спасявал, а варианта без обвързване с договор е много подходящ за такива цели - плащаш, само когато е нужно. Цената на пакета и услугата, както и относително по-доброто покритие спрямо останалите оператори беше причина да не търся други оферти и решения за използване на "чужди" SIM карти. Излизането ми извън страната и нуждата от мобилен интернет обаче промени това.

Като цяло в чужбина най-лесно достъпната алтернатива за временно ползване на интернет е през GSM оператор (изключвам работното място, интернет кафета и всякакъв подобен род обекти с безплатен WiFi, както и по-скъпите WiMax пакети, които обикновено са с обвързващи договори).
В началото стартирах с използване на телефон като 3G модем, но bluetooth връзките с лаптопа, смяната на SIM картите (voice/data) и ускореното изтощаване на батерията започна да ме уморява и реших да намеря начин за употреба на "резервния ми интернет" - VMC 3G модем K3565-Z, забутан някъде из джобовете в раницата на лаптопа.


С този пакет на цена от 99 лв. получих модема К3565-Z (буквата Z е важна и показва, че производителя е ZTE. Huawei има модел със същото обозначение, но забележете K3565-H. Двата модема нямат нищо общо като хардуер и firmware, защото K3565-H всъщност е Huawei E160X.

Най-важния факт, който трябва да отбележа, че VMC K3565-Z, НЕ Е SIM/NETWORK LOCKED!!!

Това означава, че модема може да се ползва с карти на други оператори, ако се използват следните методи:

Вариант 1. Промяна на конфигурационните настройки в софтуера Vodafone Mobile Connect

Vodafone конфигурира предварително настройките на всички оператори, с които работи в своя софтуер за улеснение на потребителя. Тези настройки са във вид на xml файлове и "живеят" в директорийната структура на приложението по оператори и държави. Тъй като инсталирания VMC не ми даваше възможност за запис на новосъздадени от мен връзки с други оператори, то се наложи да преработя съществуващата конфигурация на Мтел, като изнамерих съответния xml. Процедурата не е "висш пилотаж", но определено не е user friendly, защото освен популярните параметри като AP, user name, password, phone number, се променят няколко други като Operator ID например, който не може да бъде видян през телефонните настройки (поне не през моя Sony-Ericsson) и ми отне излишно много време за ровене в интернет през алтернативната и скъпа GPRS/3G връзка на voice картата ми.
Тази проба направих единствено от спортна тръпка, защото нито съм влюбен в GUI-то на VMC, нито мислех да го използвам при условие, че има доста по-лесен и бърз начин, подходящ за масовия потребител.

Вариант 2. Windows Dial-up

Разполагаме с инсталиран VMC, но не го стартираме (ако деинсталираме - губим драйверите). Създаваме dial-up връзка през Windows, асоциирана с нашия модем на съответния COM порт. Необходимо е предварително от Device Manager - Modem - ZTE Proprietary HS-USB Modem - Advanced / Extra command - да се въведе следната АТ команда за избор на APN:

AT+CGDCONT=1,"IP","internet.vivacell.am"

,(някои оператори не изискват изрично указване на APN, т.е. AP се открива автоматично като при dhcp. За арменския Vivacell например - APN се оставя празно, а за BeeLine - AT+CGDCONT=1,"IP","APN")
За dial-up връзката въвеждаме username/password (ако е нужно и зависи от оператора, в моя случаи - празно) с номер *99#


Единственото неудобство на Windows Dial-up връзката е липсата на статистика и невъзможността да се следи трафика, което никак не е фатално, но зависи от нуждите на конкретния случай.

Вариант 3. Инсталираме друг мениджър на връзките

Приемаме, че вече имаме инсталиран VMC и следва да го махнем. Инсталираме ZTE Join Air.


В Интернет открих множество други универсални мениджъри - безплатни и платени, но ZTE Connection Manager, освен free, ми хареса с това, че е максимално опростен и лек.

* При деинсталация ще загубим драйверите, затова ползваме тези(32 и 64-bit - изтегляме K3565-Z drivers)

Ако решим да се заиграем с модема е възможно да "убием" autorun-a на VMC при първоначално свързване с компютър, както и да "мушнем" ZTE dashboard на мястото на VMC - било във външна microSD или във вградената памет. Ето как може да се случи това:

- За конзолна връзка с модема използвам Putty (може Hyperterminal или аналогична), като предварително трябва да разберем на кой COM (serial) порт се е закачил модема от Device Manager - Modem - ZTE Proprietary HS-USB Modem - Port
Конфигурация за серийната връзка е следната:
- bit per second - от 9600 до 115200 (без значение)
- Data bit 9
- Parity None
- Stop bit 1
- Flow Control None


- Забрана на вътрешния flashdrive, съотв. autorun-a
AT+ZCDRUN=9
(разрешаване на flashdrive - AT+ZCDRUN=8)

Други интересни AT команди:

- Stay online
AT+ZOPRT=5

- check network/SIM lock
AT+ZSEC?
answer: ,

< SEC_STATUE >:
0 Initializing the encryption (Insignificant SEC_ITEMS)
1 Network Lock error. (Insignificant SEC_ITEMS)
2 Network Locked
3 Unlocked or correct MCC/MNC

:
0 No action
1 Network lock
2 (U)SIM card lock
3 Network Lock and (U)SIM card Lock

- Unlock - Тази команда се използва в случаите, когато разполагате с unlock-code и отключвате lock-нат модем. Процедурата е валидна и за GSM апарати, освен ако няма друга препоръчителна процедура за конкретния модел. Unlock-code съм купувал/генерирал за два други модема на Huawei срещу 10$ на парче от www.xorox-team.com, който ми беше препоръчан и смятам за читав, защото кодовете бяха ОК.

AT+ZNCK="unlock-code"
AT+ZNCK?
Unlock residual time 0-5

Безболезнен начин за премахване на VMC, без да правим каквито и да било промени по вградения flash на модема е като използваме външна microSD.

1. Забраняваме вградения флаш по указания по-горе начин чрез АТ команда: AT+ZCDRUN=9. Ако получите съобщение за грешка в конзолата, тогава предварително трябва да се "разкачи" флаш паметта (unmount) чрез "safely remove hardware" и спирате "USB Mass Storage Device"
2. Слагате microSD картата, предварително форматирана на FAT32
3. Изтегляте това и екстрактвате съдържанието му на флаша. (съдържа ZTE dashboard, драйвери и autorun)

По така направения начин при свързване на модема към компютър ще се стартира autorun на ZTE (само в случай, че ауторъна на removable device не е забранен на ниво Windows)

Нека да поровим в internal flash memory

Рисковия начин за премахване на VMC е чрез физическо изтриване от internal flash memory и замяната му с ZTE Join Air. Процедурата не е сложна, но ако не сте сигурни, какво точно правите - сега е подходящия момент да умъртвите модема си.
Използваме QPST - Qualcomm Product Support Tool - много сериозен инструмент за мобилни телефони, който предлага file explorer, factory test tools, low level communication settings, RF calibration tools, roaming list editor, service programming tool и др.

1. За начало ни трябват всички необходими драйвери и инсталираме VMC, ако не сме го направили до момента

2. Изтегляме QPST и инсталираме.

3. От пакета QPST стартираме "QPST" Configuration" избираме "Ports" tab


4. Добавяме порт от "Add New Port"

5. Избираме порт обозначен като "USB/QC Diagnostic" и после "OK".

6. "Start Clients" от менюто и избере "EFS EXPLORER"


7. От появилия се прозорец виждаме "Unknown" phone, маркираме и потвърждаваме с ОК.


Сега QPST прочита EFS файловата система на модема



8. Виждаме файловата структура на internal flashdrive. Добре е да направим резервно копие на ZTEMODEM.ISO. Става с десен бутон върху файла и "Copy File from Phone"... и избираме дестинацията.



Отиваме да пием кафе за 25-30 минути и точно след толкова приключва на процедурата. Вече може да затриете файла.


9. Изтегляме това, разархивираме и копираме новия ZTEMODEM.ISO в модема.

10. След приключване на процедурата по копиране излизаме от QPST configuration. Следва запитване за ресет на устройството и потвърждаваме с ОК.

Вече вашия модем е с ZTE Join Air и ползваме SIМ карти от всякакви оператори!

Старите сървъри и десктопи

В България се натрупаха доста остарели компютри и сървъри. Голяма част от тях вече не са натоварени. Често съдържат стари счетоводни или складови ( и не само) системи, които се ползват само за справки за минали периоди. Техния хардуер е в достатъчно напреднала възраст и вероятността за отказ не е никак малка. Ремонта и подмяната на дефектирали компоненти е скъпа за старите устройства, а често и невъзможна.

Има ли решение този проблем?

Отговора се крие във виртуализирането на тези машини върху един единствен нов хардуер. Поради независимостта на виртуалните машини една от друга, те могат да си съжителстват безпроблемно, няколко на брой върху една единствена физическа машина.
Ползата за крайния потребител е, че разделя операционната система и приложния софтуер от хардуера, а добрата новина е, че за това може да се ползва безплатен продукт за виртуализация. Единствения разход ще бъде покупката на нова машина с необходимите параметри за да може да държи в себе си нужните виртуални машини. Впредвид, че повечето от тези виртуални машини ще съдържат в себе си софтуер, който ще се ползва само за справки, а не за оперативна, текуща работа, то параметрите на новозакупената машина не е задължително да бъдат високи.
Следващата стъпка е мигрирането на данните от физическата към виртуалната машина. Процеса не е деструктивен за физическата машина и едва след, като се убедим, че виртуалната машина е създадена и функционира успешно, можем да „пенсионираме” физическия й първообраз.
Обикновените (физически) сървъри и настолни компютри работят с много на брой отделни файлове. Те могат да бъдат както от операционната система, така също драйвери, приложен софтуер или просто потребителски данни. Виртуализацията разделя софтуера от хардуера, вмъквайки един допълнителен слой между тях и поставя данните за всяка виртуална машина (VM) в един единствен файл на физическия диск (или масив). VMware използва VMDK файлов формат. Такъв файл представлява пълна и независима виртуална машина под VMware продукти или други платформи, които поддържат VMDK файлове като XVM, QEMU или VirtualBox.

Основните предимства са простота и удобство. Един файл (*.VMDK), например, е лесно да се премести между физически сървъри, чрез студена или жива миграцията в платформа за виртуализация. Лесно е да се постигне защита на информацията чрез снимки на състоянието (snapshots). Преди въвеждането на специализираните софтуерни инструменти, беше невъзможно да се възстанови само част от VM, като например обикновен потребителски документ. Налагаше се да се възстанови цялата VM, обикновено на резервен сървър, вместо на оперативния сървър, като едва тогава архива на повредения файл можеше да бъде извлечен. Днес, възстановяването на отделен файл от виртуалната машина не е проблем. Това не изключва задължението на администраторите да разработят планове за възстановяване след авария.

Файлoвият формат VMDK се конкурира с Microsoft Virtual Hard Drive (VHD) дисков формат, използван в Hyper-V платформата. Дисковите формати не са директно съвместими и от това следва, че съществуващите виртуални машини не могат да функционират върху различен Hypervisor. В много случаи, виртуални машини трябва първо да бъдат мигрирани върху физически сървър (V2P) за ефективното премахване на предходната виртуализация. Новият Hypervisor тогава ще създаде нови виртуални машини, като се използва нов формат на диск. Съществуват и инструменти на други разработчици за преход от един формат в друг.
Процеса на виртуализация на стари физически машини носи спестявания от опертивни разходи и повишава сигурността на данните при минимална инвестиция.
Примери за виртуализиращ сървър ще намерите в следващия пост.

Replacement for NetScreen Remote VPN client

... или разделям ли се с Juniper NetScreenRemote VPN client?

От скоро преминах към Windows 7 Ultimate 64-bit и останах разочарован като установих, че Juniper няма да разработват своя IPSec VPN клиент - NetScreenRemote (всъщност е на SafeNet) за 64-bit платформи и изцяло за Windows 7. Продажбата на 32-bit версии също е преустановена. За повече информация тук.
Освен разочарован се чувствам и частично прецакан, защото като добросъвестен клиент имам закупен пакетен лиценз за 100 потребители (разбира се по-стара версия, когато перспективите за 64-bit OS на клиентски машини бяха далечни, но все пак таях скрити надежди за безплатен или неболезнен ъпгрейд към по-нови версии). Но с големите не може да се бориш и затова реших да намеря алтернативно, безплатно и работещо решение на проблема.




Shrew VPN е безплатен IPSec VPN клиент за отдалечен достъп. В зародиш е бил проектиран за осигуряване на IPSec tunnel между windows хост и opensource vpn gateway - OpenSWAN, FreeSWAN или StrongSWAN. Впоследствие поддръжката му е разширена за Linux и BSD, както и за 64-bit. Предлага доста екстри характерни за комерсиалните продукти, което го прави много подходящ и съвместим с продукти на: Cisco, Juniper, Checkpoint, Fortinet, Netgear, Linksys и много други.

Ще разгледам в детайли инсталация върху Windows 7 Ultimate 64-bit и необходимата конфигурация при настройка на ShrewVPN Client v.2.1.5 към Juniper SSG140 firmware 6.2.0r2.0 (тестван и с SSG5 firmware 5.4.0r6)

Juniper SSG140 конфигурация - само CLI config, че не ми се занимава със скриин шотове на WebUI, а и за заинтересуваните от проблема предполагам не е проблем.

1. Създаваме vpn gateway
- тъй като използвам XAuth - първо създавам универсален IKE потребител за пробата - shrew

set user SHREW
set user SHREW type ike
set user SHREW ike-id fqdn shrew.domain.bg
set user SHREW share-limit 10
set user SHREW enable

- създавам Local Key Group и дабавям SHREW user, която после ще закачим към vpn-a

set user-group SHREW_GROUP
set user-group SHREW_GROUP user SHREW

- създавам Auto Key Advanced Gateway

set ike gateway SHREW dialup SHREW_GROUP Aggr local-id shrewvpn.domain.bg outgoing-interface eth0/2 preshare my_password proposal pre-g2-aes128-sha pre-g2-aes128-md5 pre-g2-3des-sha pre-g2-3des-md5
set ike gateway SHREW dpd-liveness interval 30
set ike gateway SHREW nat-traversal keepalive-frequency 5

NOTE: Shared IKE ID dial-up group configurated. Please note XAUTH server must be turned on as well.

set ike gateway SHREW xauth

- създавамe vpn-a:

set vpn SHREW-VPN gateway SHREW no-replay tunnel idletime 0 proposal nopfs-esp-3des-sha nopfs-esp-3des-md5 nopfs-esp-aes128-sha nopfs-esp-aes128-md5

- създавамe XAuth IP Pool, ако не е създаден по-рано, аз използвам съществуващия:

set ippool Dialup_users 192.168.200.xxx 192.168.200.xxx
set xauth default ippool Dialup_users
set xauth default dns1 192.168.xxx.xxx
set xauth default dns2 192.168.xxx.xxx
set xauth default wins1 192.168.xxx.xxx

- създавам IPSec Policy

set policy name SHREW-VPN from Untrust to Trust Dial-Up VPN 192.168.xxx.0/24 ANY tunnel vpn SHREW-VPN

- създавам XAuth user:

set user shrew.test
set user shrew.test type xauth
set user shrew.test remote ippool Dialup_users
set user shrew.test password my_strong_pass

Инсталация и настройка на клиента:

1. Изтегляме продукта от тук - съответно последната ver.2.1.5 (2.57 MB)
2. Инсталираме с последователността - Next > Next > INSTALL ,като за целта е нужно да сме потребител с административни права. За последващо използване на клиента от други потребители това не е нужно.
3. Стартираме ShrewSoft VPN - Access Manager


4. Създаваме нов профил чрез Add.


5. Client - Firewall Options
NAT Traversal е ясно защо конфигурираме, но интересния момент е поддръжката на IKE Fragmentation конкретно в ShrewSoft VPN client. Използвайки IPSec, знаем че пакета се енкапсулира с нов хедър и така MTU може да набъбне, особено използвайки Cerificate Authentication и пиърите обменят сертификати. Тогава именно чрез IKE fragmentation става възможно пренасянето на пакети през NAT-ващи рутери или през такива конфигурирани да режектват по-големи пакети. Затова в по-горната картинка MTU e сетнато на 1380!


6. Name resolution - WINS/DNS


7. Authentication - Local Identity


8. Authentication - Remote Identity


9. Authentication - Credentials


10. Phase 1


11. Phase 2


12. Policy - указваме отсрещната мрежа, която ще достъпваме, така както е зададена в политиката на VPN-a в SSG140.


13. Connect - Въвеждаме име и парола


14. Резултатът / Connection Status


и виждаме виртуалния адаптер с очакваните настройки:



15. Бележки

На пръв поглед прави приятно впечатление ресурсите на паметта, които използва за разлика от NSR.


Много удобна е възможността за import / export на конфигурационния файл. Това улеснява дистрибутиране на настройките на VPN клиента към крайни потребители без излишно усложняване на живота им.
Липсва опция, конфигурацията да бъде заключвана, правейки аналогия с NetScreenRemote, което беше допълнителна екстра за сигурността.
Функция AutoConnect се постига, чрез шорткът на ipsecc.exe със следните command line параметри:

ipsecc -r "name" [-u ][-p ][-a]
-r - Connection name с разширението .vpn в кавички
-u connection user name
-p connection user password
-a auto connect
или в моя случай имам следното в Target line на шорткъта:

"C:\Program Files\ShrewSoft\VPN Client\ipsecc.exe" -r "shrew_test.vpn" -u shrew.test -p shrew.test -a

След което шорткъта отива в StartUp.

Дали създава проблеми при съжителство с други VPN клиенти и по-конкретно с NSR е рано да ви кажа. В последствие ще направя тестове с други версии на Windows преди да го пусна в употреба в корпоративна среда.

SIP Trunk към vivacom

Vivacom предлага SIP Trunk до фиксираната си мрежа чрез услугите: VIP business и Дейтафон

"Предоставя по изградена IP свързаност (SDSL, наета линия, MAN) към IP мрежата на БТК Нет. При клиентите се инсталира VoIP gateway (собственост на клиента или предоставен от VIVACOM).
Клиенти които разполагат с комуникационно оборудване с Ethernet интерфейс и SIP протокол могат да ползват услугата без VoIP gateway.
Услугата се предлага и с други некомутируеми IP услуги на VIVACOM като IP VPN и бизнес интернет. "

vivacom не предлага астериск sip.conf образец към който да се придържате. Вероятно на този етап sip трънковете с asterisk са малко и където услугата е налице - се използват VoIP gateways . Ето една работеща конфигурация за SIP Trunk към vivacom.


[vivacom]
type=peer
context=default
host=10.102.255.215
disallow=all
alow=alaw
insecure=port, invite
canreinvite=no
qualify=yes
fromdomain=10.102.255.215
dtmfmode=rfc2833

Практически пример за iSCSI target - Част 1

... или как да намалим разходите и въпреки това да получим производително решение за съхранение на данни

Какво е iSCSI?

iSCSI е технологичен стандарт за предаване на SCSI команди и данни на блоково ниво по IP мрежи между клиент и компютър (target). Тази мрежова свързаност може да се използва в рамките на LAN, WAN или интернет. iSCSI устройства могат да са HDD, лентови устройства, CD/DVD устройства, които посредством хардуерен iSCSI HBA (Host Bus Adapter) или софтуер инсталиран на компютър - iSCSI инициатор, се свързват помежду си. В резултат iSCSI устройствата се "виждат" като локални на компютъра, към който са свързани по TCP/IP.
Често правена грешка е неразграничаването на iSCSI SAN и NAS Network Attached Storage). И двете използват една и съща IP мрежа, но iSCSI ни осигурява blocklevel достъп до данните (дава ни диск), а NAS - filelevel (дава ни файл).

Предимства и недостатъци ... или iSCSI vs FC

Темата е доста обсъждана и обикновено се сравнява с FC (Fibre Channel), като и двете технологии имат своите силни и слаби страни. Доводите винаги са технически и икономически обосновани, НО пречупени през призмата на частния случай. Ето това прави първоначалния избор на сторидж концепция толкова труден и объркващ.
Основно предимство на iSCSI технологията е, че стандарта е отворен - предпоставка за значително последващо развитие. Както някои казват: SCSI технологията е минало, Fibre Channel сторидж мрежите са настояще, а iSCSI сторидж мрежите са бъдещето.

Няма еднакви условия дори при просто сравнение между iSCSI и FC. Теоритично iSCSI е по-напредничава, но пък няма този "стаж" и комерсиална работа като FC. Беглото наблюдение е, че форумите са пълни с постинги относно iSCSI и съпътващи проблеми с връзки и настройки към инициатори от страна на MS Hyper-V или vmware vSphere 4 например. Това дори е радващо, доказва засилен интерес и работа в тази насока, но при Fibre Channel темите са малко "по-възвишени" - оптимизация, перформанс, резервираност и т.н. Технологията е по-узряла, защото е "поливана" с пари на големи производители и в общия случай, би се класифицирала с принципа: "Просто работи" ... но на каква цена?

Това е един от козовете на iSCSI пред FC - първоначалната цена на придобиване, която в някои проекти и решения е по-ниска в пъти. Причината е в преносната среда - ethernet и IP, т.е. използва се наличното мрежово оборудване. Мрежовата същност на протокола прави iSCSI несравимо подходящ за дистрибутирани мрежи (VPN инфраструктури), каквито вече има и в малкия бизнес.
Нека припомня, че цените на IT продуктите непрекъснато падат, в това число и на мрежовото оборудване. Не от скоро можем да закупим 4 портов гигабитов мрежов контролер от класен производител по-евтино спрямо 4 Gb FC HBA (Host Bus Adapter), ако се опитваме до постигнем същата скорост на преносната среда посредством обединение (aggregation) на мрежовите интерфейси.
Трябва да споменем и наличните вече на пазара 10 Gb мрежови интерфейси. По отношение на цената, на този етап не са особено конкурентни, но това ще се промени в близките 1-2 години. Софтурните инициатори постоянно се оптимизират и употребата им при 10Gb контролери ще се увеличава, въпреки че определено ще води до повишаване натоварването на процесора, дори при наличен TOE (TCP/IP Offload Engine) в мрежовия контролер. В това отношение технологията има леки, детски болести, но като цяло я очаква светло бъдеще.

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

Направи си сам

Разполагаме със стар, но все още работещ модел NAS - DELL Power Vault 705N. Знаехме, че яздим умрял кон и решихме да му даден зоб и да го подковем.

DELL Power Vault 705N параметри:
Drive Capacity : 4x80GB IDE type
External I/O Ports : 10/100 BaseT
Onboard Controller: Promise IDE RAID levels 0,1,1+0,5
Data Cache : 64MB SDRAM cache memory
CPU : 233 MHz Intel Pentium Processor
Max Disks & LUNs : 4



Максимално поддържания капацитет на HDD е 160GB IDE и разполага с един 10/100BaseT интерфейс. Това породи идеята да преобразим NAS-a в SAN и се обобщи в смяна на дънната платка с mITX със SATA портове и замяна на хард дисковите устройства с 4x1TB. Единствено кутията и захранващия блок бяха използваеми.

Да разгледаме компонентите

Case: 1U rackmount - елегантна черна кутия, чийто малък недостатък е липсата на сменяеми HDD чекмеджета, т.е дисковете са статично монтирани, което всъщност не е болка. Тук намесих ъглошлайф и бормашина за осигуряване нужните отвори за задния панел на дънната платка и за нейното закрепване. Отделих време и на допълнителни отвори за вентилация, определени прецизно по метода на "Очомер" и "Шесто чувство".



PSU: Захранващ блок - максималната мощност на захранващия блок е 150W, която всъщност е на ръба на необходимото, поне в момента на стартиране на системата, защото пиковото натоварване е около 110W (MB+CPU) + 40 W (HDD) - (стойностите са приблизителни). За да се избегне стартовия пик на консумация, получаващ се при първоначалното развинтване на хард дисковите устройства и за да не се активира защитата по ток, се бях подготвили с просто електронно, времезакъснително реле за два от дисковете, което трябваше да играе роля на SATA/SAS backplane и забавя първоначалния им старт с приблизително 1/2 до 1 секунда. Но след неколкократни опита се установи, че това е ненужно, а и след влизане в работен режим средната консумация се установява на около 95-100W

MoBo: Jetway JNC62K Socket AM2/AM2+ - за проекта беше нужно miniITX дъно с оглед габаритните размери, като основните изисквания бяха минимум 4 бр. SATA II порта и 2 или повече бр. гигабитови мрежови интерфейса за aggregation / teaming и не на последно място поддръжката на адекватен процесор, който да отнесе целия "бой" - софтуерен RAID и мрежови трафик.



Параметри:
- nVidia NF-8200 (MCP78S) Chipset AMD socket AM2/AM2+ Quad Core Opteron™ & Phenom™
- Mini-ITX motherboard with 2x Gigabit LAN, VGA, DVI-I, IDE, 4x SATA II, 6 Аudio
- 8x USB 2.0 Ports and integrated DirectX 10 graphics with HD-DVD, BluRay
- up to 2GB in one 240-pin DIMM socket for unbuffered Dual DDR2 667/800 SDRAM
- 1x 20pin ATX Power Connector and 1x 12V 4pin ATX Power connector (both are required).

CPU: AMD Athlon X2 7750 BE - 2.7GHz, dual core, L3 Cache 2 MB, Socket AM2+



Да! ... AMD 7750, Black Edition. Първоначалния замисъл беше Athlon x2 с понижена консумация до 45W, но спазихме принципа на мечо Пух. Вярно е, че изчислителна мощ никога не е излишна, особено при софтуерен RAID, но си признавам, че тук малко се поизхвърлихме, при условие, че комерсиални продукти в този клас използват Atom 270 или Atom 330 (dual core). От друга страна това показва, че колкото и да се "изръсите", трудно ще надхвърлите цената на готов NAS/SAN в този клас. Дали да потрием ръце предварително и какво да очакваме, тестовете ще покажат.

RAM module: Kingston, 1GB DDR2, 800MHz - нищо особено.

HDD: 4 броя Seagate Barracuda ST31000340NS/SN06 - 1TB, SATA II, 7200 rpm
Този модел е сървърен и предвиден за 24/7 натоварване с MTBF - 1.2M часа. Оптимизиран за RAID конфигурации и оборудван с 32MB cache. За повече информация и параметри тук

За радиатора на CPU и неговото захващане бяха пoложени труд и творчество. Основното затруднение дойде от факта, че захвата на АМ2 сокета е десктоп ориентиран. В този случай посоката на ребрата на всички налични сървърни 1U passive радиатори беше неподходяща за нас и се наложи да "завъртим" на 90о монтажната планка. Това позволи странично обдухване на радиатора и компонентите на платката, както е на снимката.



Наличните вентилатори в кутията бяха заменени с нови. Специално внимание се обърна за качественото обдухване на процесора чрез 2 бр. 39 mm турбо вентилатора на 8000 rpm.



Boot device: DiskOnChip - Apacer 256MB IDE - с FreeNAS 0.7RC1 AMD64



Приблизителни цени на използваните компоненти.



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

Следва инсталация и конфигуриране на FreeNAS. Създаване и монтиране на RAID и iSCSI target. Всичко това, наред с тестовете за перформънс към инициатори на MS Windows Server 2008 и vmware ESXi 4 очаквайте скоро в Практически пример за iSCSI target - Част 2

Когато забележиш, че използваш умрял сървър – изведи го от експлоатация

Стара индианска мъдрост за Преструктуриране на умрелите коне
...но ноже да се приложи и при сървърите

За разлика от индианците, какво прави ръководството на една фирма, за да спаси умрелия кон:

1.Обявява: - "Никой кон не може да е толкова умрял, че да не може да се язди повече!"
2.Променя критериите, по които определя, кога един кон е умрял;
3.Дава порция зоб на умрелия кон и му сменя подковите;
4.Събира умни конегледачи накуп, да анализират коня;
5.Посещава други места, за да види, как там яздят умрелите коне;
6.Сравнява различни видове умрели коне;
7.Впряга много умрели коне заедно, за да стане един от тях по-бърз;
8.Проучва, дали не са се появили по-нови, по-модерни, по-добри умрели коне;
9.Избира "елитна" група ездачи, която да намери ново приложение на умрелия кон;
Накрая когато конят започне вече съвсем нетърпимо да мирише казва, че - "Неговият кон е умрял по-бързо, по-красиво от други умрели коне и че не е имало друг избор!"

Идеен източник за публикувания материал

Сегмент от парламентарна LAN мрежа

... грозно и показателно

Ден на отворените врати на Народното събрание - 01 ноември 2009.

В коридор на втори етаж зад терасата виждаме "сегмент от парламентарната LAN мрежа"

... колко смях има на този свят ... Боже!

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

"Колегите" от Дирекция "Информационни и комуникационни системи" на Народно събрание вероятно не знят, че и за по-малко са "хвърчали" ИТ кратуни в частния сектор, но "тури му пепел" ... мизерници има по всички "етажи на властта" :)

Hyper-V R2

Live Migration

Една от ключовите функции е Live Migration. VMware вече имат такава технология с наименованието vMotion. Тя позволява на жива машина (виртуална) да бъде преместена от един физически хост на друг физически хост. Quick Migration на Microsoft върши чудесна работа, но изисква рестарт на виртуалната машина, a клиентите свикваме бързо с удобствата. На софтуерния гигант му се наложи да догонва VMware. Голямата спирачка в Hyper-V за жива миграция беше липсата на файлова система способна да работи в клъстер режим. NTFS е стандартизирана и широко използвана, но не е клъстерна файлова система. Проблемът с файлова система NTFS е, че няма възможност за два различни хоста да погледнат в същия том и да са в състояние да разберат кой, на кои файлове е собственик. Наложи се да бъде създаден CSV (cluster shared volume). Само за аналогия VMware използват VMFS (virtual machine file system), която поддържа vMotion. С две думи клъстерната файлова система позволява да бъде монтирана едновременно на няколко сървъра. От тази гледна точка тя става споделена за тези сървъри. Идеята е, че виртуална машина работеща на даден физически хост, с виртуални дискове, разположени на споделена файлова система – видима и от останалите физически хостове, може да бъде преместена на друг хост, стига и той да „вижда” същата файлова система. Специалистите по съхранение на данни твърдят, че CSV е в ранна детска възраст. Това в никакъв случай не означава, че не работи или има проблеми. Просто все още липсват някои екстри, като допълнителни възможности за управление на сториджа, има нужда от обогатяване на възможностите за репликация и т.н.
За момента можем да разглеждаме CSV, като тунингован NTFS. Ясно е, че е по добре да се тръгне от нещо познато и утвърдено. Все пак бизнес модела на Microsoft досега беше да се използват подобни решения от други разработчици. Сега ще се наложи да създадат свой продукт, а мотива е убедителен.

Какво се случва при живото мигриране?

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

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

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

Конкуренцията в областта на виртуализацията нараства. Залозите стават все по-високи.

Нека победи по-добрия!

Клиента може само да спечели.

Upgrade версия на WINDOWS 7

Публикувам информация изпратена ми от Милко Милев /Windows 7's launch team/:

ОТ WINDOWS XP И WINDOWS VISTA ДО НОВАТА ОПЕРАЦИОННА СИСТЕМА

След официалното пускане на Windows 7 на 22 октомври тази година потребителите ползващи Windows XP и Windows Vista ще имат възможността за бърз ъпгрейд на операционната система до Windows 7 без да е необходимо закупуването на “full” версията на софтуера, а създадената за целта “upgrade” версия.

“Upgrade” версията е най-удобният и практичен начин за обновяване за потребители, ползващи Windows XP и Windows Vista, тъй като продуктът запазва всички потребителски файлове . За улеснение е създаден инструментът Windows Easy Transfer за преместване на документи, снимки, видео файлове, музика и настройки между два компютъра или между стара и нова инсталация на Windows. Помислено е и за възможността за ъпгрейд до Windows 7 в зависимост от конкретното издание на операционната система, която се ползва – Windows Vista Home Premium, Windows XP Professional, 32-bit Windows Vista, 64-bit Windows и т.н.

“Upgrade” версията на Windows 7 изисква наличието на по-стара операционна система на компютъра - XP или Vista, за да може тя да бъде обновена до най-новия продукт. Пълната “Full” версия не изисква наличието на операционна система и е необходима ако компютърът ще бъде форматиран. С тези разработки компанията е помислила за улеснение, както на потребителите на XP и Vista, така и за новите потребители на Windows.

За ползващите Vista ще е по-лесно и бързо да обновят операционната си система, тъй като единственото необходимо е наличието на инсталационния диск, с който да направят процедурата. За онези, които работят с XP процесът ще е малко по-различен. Първо ще трябва да установят дали е наличен минимум от системни изисквания с помощта на безплатна за сваляне Windows 7 Upgrade Advisor от страницата на компанията: http://windows.microsoft.com/. Програмата открива потенциални проблеми с хардуера и наличните устройства, които могат да афектират инсталационния процес. Ако системата притежава необходимите изисквания, тогава потребителят може да обнови софтуера си. Microsoft са подготвили и съветник стъпка-по-стъпка как да протече процесът по обновяването на страницата на компанията, за да не се стига до загуба на данни и информация по време на инсталацията.

Търговците – партньори на Microsoft също предоставят възможност за „ъпгрейд” от Vista до Windows 7 на вече закупен компютър или лаптоп.

Microsoft Hyper-V R2 лицензионен модел и ценообразуване

Microsoft Hyper-V Server 2008 R2 е самостоятелен продукт, който вече е свободно достъпен за безплатно сваляне през Microsoft Download Center. Той има всички нови функции внедрени в R2, но за да могат да се ползват се изискват инвестиции в Microsoft System Center и System Center Virtual Machine Manager (SCVMM). Аналогията с VMware може да откриете в тази статия.

В дадените примери по-долу ще дам препоръчителни цени за крайни клиенти за територията на България по програмата OLP (Open License Program) без включена софтуерна осигуровка. Те са само база за сравнение. Вашите цени могат да се различават поради използвани промоции, договорени отстъпки с доставчици или промяна на ценовата политика от производителя.

Microsoft не изисква лицензи за клиентски достъп (CAL) за самия Hyper-V. Това не се отнася за операционните системи във виртуалните машини, хостващи се на Microsoft Hyper-V Server 2008 R2.
Темата с лицензирането на операционните системи във виртуална среда, както и окомплектоването на Hyper-V с трите версии на Microsoft Windows 2008 Server R2 (Standard, Enterprise, Datacenter) е описана подробно в тази статия.

Да отключим функциите на Hyper-V

За да създадем и поддържаме Hyper-V виртуална среда, трябва да си закупим Microsoft System Center и Microsoft System Center Virtual Machine Manager. MSC VMM 2008 R2 Management license е необходим за управление на всяка виртуализирана операционна система.

MSC VMM 2008 R2 Enterprise Server Management License покрива неограничен брой виртуални машини върху един физически сървър и струва 958 евро без ДДС.

MSC VMM 2008 R2 Client Management License включва сървърната и клиентската част на VMM.Цената му е 29 евро без ДДС.
Има два случая на лицензиране - на потребител или на операционна система.
И в двата случая цената е една и съща, но се ползва само единия лицензионен модел.

MSC VMM 2008 R2 Workgroup Edition включва сървърната и клиентската част на VMM и е ограничен до управление на максимум пет физически хоста от една конзола. За сметка на това – няма нужда от лиценз за управляващ клиент.
Цената му е 556 евро без ДДС.

Лошата новина е, че само MSC VMM не е достатъчен за пълната функционалност. Той дава само основната, конкретно свързана с виртуализацията. За да ползваме всичко налично са необходими и другите компоненти от Microsoft Systems Center. Конкретно за Hyper-V са ни необходими още:

- Configuration Manager,
- Operations Manager,
- Data Protection Manager,

или System Center Essentials, като по-олекотен вариант.

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

Налице са три варианта:

System Center Server Management Suite Enterprise Edition - включва управление на физически и по-слабо натоварени виртуални сървъри. За всички компоненти важи Enterprise Server лиценз за управление :
- Operations Manager 2007 R2,
- Configuration Manager 2007 R2,
- Data Protection Manager 2007,
- Virtual Machine Manager 2008,
Добавен е Management Server лиценз за Virtual Machine Manager 2008, както и правата да управлява четири виртуализирани операционни системи на един физически хост. Цената е 1320 евро без ДДС, но с включена софтуерна осигуровка.

System Center Server Management Suite Datacenter Edition се препоръчва за управление на физически и силно натоварени виртуални среди. Той включва Enterprise Server лицензи за управление на:
- Operations Manager 2007 R2,
- Configuration Manager 2007 R2,
- Data Protection Manager 2007,
- Virtual Machine Manager 2008,
Добавен е Management Server лиценз за Virtual Machine Manager 2008, както и правата за управление на неограничен брой виртуализирани операционни системи , но на база физически процесор.Цената е 825 евро без ДДС за процесор, но с включена софтуерна осигуровка.

Олекотения вариант е Microsoft System Center Essentials 2007

Той изисква сървърен лиценз за управление и лиценз управление (Management Licenses) към всяка управлявана операционна система. Сървърния Management License е необходим за управлението на всяка сървърна операционна система, a клиентския Management License е необходим за управлението на всяка една десктоп операционна система.

Microsoft System Center Essentials 2007 е технически ограничен (поради по-ниската цена) до управлението на 30 Windows Server –a и 500 Windows десктоп базирани операционни системи. Този продукт (както и Essentials 2007 + SQL Server 2005) идват с лицензи за управление на 10 сървърни и 50 десктоп операционни системи. Допълнителни Server лицензи за управление могат да се закупят по 1 или в пакет по 5 бройки. При клиентските лицензи за управление вариантите са пакети по 5 или 20 бройки. Цените са както следва:

Базов пакет Microsoft System Center Essentials 2007 с 10 сървърни и 50 клиентски лиценза – 1770 евро без ДДС.
Базов пакет Microsoft System Center Essentials 2007 + SQL с 10 сървърни и 50 клиентски лиценза – 2590 евро без ДДС.

Допълнителен пакет от 5 клиентски лиценза – 89 евро без ДДС.
Допълнителен пакет от 20 клиентски лиценза – 355 евро без ДДС.

Допълнителен пакет от 1 сървърен лиценз – 89 евро без ДДС.
Допълнителен пакет от 5 сървърни лиценза – 443 евро без ДДС.

Странната част от лицензирането е при операционни системи, различни от тези, за Windows-базирани персонални компютри и сървъри. Те също се нуждаят от клиентски или сървърен лиценз за управление според случая.
Изключение правят операционни системи лицензирани да изпълняват сървърния софтуер на Essentials 2007 или операционни системи на които не се изпълнява никакъв приложен софтуер. Към изключенията се добавят и мрежови устройства, чиято функционалност не превишава ниво 3 от OSI модела.