Съхранение и виртуализация: Част 5
Отдалечено съхранение за виртуални машини
Тъй като iSCSI технологиите разчитат основно на карта с мрежов интерфейс, достатъчно е те да поддържат виртуален NIC, за да няма проблеми. Майкрософт поддържа iSCSI във Virtual Server 2005 R2, Майкрософт предлага и безплатен iSCSI инициатор за употреба с Windows машини. Той може да бъде инсталиран на виртуалната машина, за да се свързва директно с дадена iSCSI цел.
При SAN положението е малко по-различно. Тъй като host bus адаптерите (HBA) са физически карти, които трябва да бъдат инсталирани на машината, необходимо е да се осигурят определени драйвери или да се емулира хардуерът. Не са известни платформи за виртуализация, които имат такава поддръжка. Разбира се, винаги може да се ползва HBA на операционната система. В Microsoft Virtual Server например могат да се монтират отдалечените дялове и да се използва функцията за “свързан диск”, която да ги направи достъпни за виртуалната машина.
Ще работи ли Virtual Server с iSCSI и SAN-ове?
iSCSI и SAN технологиите са създадени с цел да предлагат на компютрите съхранение оглед на местоположението. От гледна точка на операционната система повечето приложения и софтуер не могат да различат локалното съхранение от монтираните iSCSI или SAN дялове. Следователно да, определено могат да се пускат файлове на виртуалната машина, които се съхраняват на iSCSI устройство или на SAN конфигурация.
Това води до въпроса за производителността. Трябва да се изпробва общата производителност, преди да се избере отдалеченото съхранение, защото виртуалните машини могат да предизвикат много входно/изходни процеси на диска. В някои случаи добре управляваната SAN или iSCSI архитектура подобрява производителността, но друг път проблеми като латентност или нисък капацитет на връзката могат да доведат до забиване на виртуалната машина (не бива да се забравя, че операционната система очаква достъп до локален твърд диск и не желае да чака дълго за извършването на входно/изходните процеси на диска). Като цяло употребата на Virtual Server заедно с отдалечено съхранение може да подобри производителността и управляемостта, но със сигурност ще натовари сериозно конфигурацията.
Внедряване на виртуализация на съхранението и сървърите
Опознаването на хардуера, както и проверката на съвместимостта са важни стъпки при внедряването на виртуалните сървъри и виртуалното съхранение.
Виртуализацията на съхранението си остава сравнително нова технология, виртуализацията на Windows сървъри е още по-нова, а доброто сработване помежду им отнема време. Все по-често се срещат проблеми със съвместимостта, предизвикани по-вероятно от слаба производителност, отколкото от тотална несъвместимост. За да се осигури адекватна производителност, е важно да се познават и разбират продуктите, които се внедряват.
Разбира се, трябва да се знае и какво ще се виртуализира. Една от първите стъпки при всеки проект за виртуализация е изготвянето на инвентар на сървърите, устройствата за съхранение и всички други компоненти, които ще участват. Това включва неща като host bus адаптери (HBA) и комутатори за мрежи за съхранение (SAN), както и ревизиите на софтуера и фирмуера.
Трябва да се проверят списъците за съвместимост на хардуера (HCL) на двата продукта за виртуализация, за да е сигурно, че конфигурацията отговаря на тях. Това става все по-лесно, тъй като доставчиците на продукти за виртуализация се опитват да ги направят оперативно съвместими. Така например VMware агресивно промотира своята VMware Infrastructure 3, която свързва техния ESX Server 3 и други подобни продукти с виртуализацията на съхранението и свързаните с това софтуер и хардуер. Наскоро Emulex и OLogic обявиха, че имат списъци за съвместимост, които се поддържат от архитектурата на VMware.
Най-добрият вариант е да се започне с виртуализация на леко натоварените сървъри както с цел добро съотношение цена-печалба, така и от гледна точка на производителността. Ако има три сървъра и всеки се натоварва по-малко от 30%, виртуализирането им на един сървър ще има повече икономически предимства, отколкото ако се започне с виртуализация на натоварените сървъри.
Проблеми с производителността
Учудващото при съвременната виртуализация е ниският овърхед, съчетан с повишените разходи на време, производителност и капацитет. Разбира се, тази цена си струва, ако води до ползи, но трябва да се следят разходите. Това означава да се наблюдават базисната производителност на системата с Iometer или други специфични за всеки доставчик инструменти.
Какво е NPIV и защо е важно?
NPIV е продължение на стандарт, който вече е дефиниран в протоколите на fibre каналите и позволява да се преодолее лимитът от един инициатор/цел. За да се възползваме от него, NPIV трябва да се поддържа както от HBA, така и от комутатора, за да се генерира и позволи допълнително виртуално световно име на порта (WWPN). Тук срещаме неизбежен сблъсък на идеали – виртуалните сървърни среди искат да използват средите за виртуално съхранение. Ако HBA, комутаторът и масивът за съхранение могат да създадат “виртуалната” тъкан, ще стане възможно създаването на връзки за единична употреба, подобни на VPN или VLAN. В това число са и технологиите, които се нуждаят от сигурна връзка между виртуалния сървър и виртуалния LUN, като междувременно LUN и комуникациите остават незасегнати от точка до точка. Това позволява дискриминация на трафика и решава много други потенциални проблеми с мрежата за съхранение.
Свързване на виртуалните машини с fibre channel устройствата
Виртуалните машини не могат да се свържат директно с fibre channel LUN. По скоро ESX сървърът управлява съхранението, към което е прикрепен, и балансира натоварването. Той трябва да бъде зониран и свързан към съхраняващите LUN като всеки друг сървър, а софтуера на ESX сървърът определя кои LUN се виждат или са достъпни от отделните виртуални машини. Тъй като мрежовото съхранение (чрез FC или iSCSI) е сред изискванията за възстановяване от бедствия, това ускорява способността на другите ESX сървъри да виждат LUN при failover и HA конфигурациите.
