Stratus Technologies wprowadził na rynek nowe modele ftServer 2600, 4500 i 6300 oparte na wydajnych procesorach Intel Xeon 5500 Nehalem. Rozwiązania nowej generacji oferują w porównaniu ze swoimi poprzednikami wyższą wydajność, o wiele większą pojemność pamięci RAM, dysków wewnętrznych oraz znacznie korzystniejszy współczynnik cena-wydajność.
Stratus zawdzięcza swoją reputację wyjątkowej niezawodności produktów. Gdy wprowadza nową ofertę, taką jak kolejna generacja serwerów ftServer, klienci mogą być pewni, że otrzymują najlepszą w branży ochronę przed nieplanowymi przestojami i utratą danych.
W dokumencie PDF znajdują się m.in. następujące informacje:
- porównanie nowych serwerów ftServer z ich starszymi modelami pod względem właściwości i korzyści,
- opinie firmy Microsoft na temat baz danych SQL Server o znaczeniu krytycznym na serwerach ftServer,
- planowany termin udostępnienia serwerów w wersjach obsługujących systemy Linux i vSphere.
Wirtualizacja nie oznacza odizolowania aplikacji, czy podczas planowania wirtualizacji środowiska informatycznego brana jest pod uwagę ich wymagana dostępność?
Użytkownicy technologii wirtualizacyjnych wiedzą, że dostępność aplikacji jest bardzo ważna. Czy znają jednak opcje dostępności oferowane w wirtualnych infrastrukturach, które kupują? Zdaniem analityka Dana Kusnetsky’ego, wiele osób ich nie zna.
W artykule „Problemy, którym można zapobiec: dlaczego użytkownicy technologii wirtualizacyjnych zapominają o dostępności?”, omówiono problematykę, jak „wtopić” funkcje wysokiej dostępności w środowisko już na etapie jego tworzenia, tak aby nie dodawać ich dopiero wtedy, gdy architektura i rozwiązania są już gotowe.
Materiał ten zawiera następujące zagadnienia:
- Czym jest wirtualizacja?
- Tworzenie środowiska o wysokiej dostępności
- Metody zwiększania dostępności oparte na sprzęcie i oprogramowaniu
- Odporność na awarie a dostępność
- Jaką dostępność można uznać za wystarczającą?
- Jak podejmować decyzje o zakupie rozwiązań?
Począwszy od dnia 9 października 2008 roku fabryka nie przyjmuje zamówień na rozwiązania ftServer 2500, 4400, 6200.
Ostatnie zamówienia realizowane będą do dnia 19 listopada 2008 roku.
End of Sericve nastąpi nie wcześniej niż 9 października 2011 roku. Data EOS ogłoszona zostanie z półrocznym wyprzedzeniem.
Nowe zamówienia przyjmowane będą dla rozwiązań ftServer 2510, 4410, 6210.
Systemy przetwarzania wysokiej wydajności (High Performance Computing) to szybko rosnący segment rynku, który jak nigdy dotąd przynosi korzyści z dostępnej obecnie mocy obliczeniowej serwerów w architekturze x86. Dzięki tej wydajności coraz więcej małych oraz dużych przedsiębiorstw korzysta z zalet klastrów HPC.
Przestój pojedynczego serwera (node) rozwiązania klastrowego nie jest do zaakceptowania przez środowisko HPC. Microsoft wspiera systemy przetwarzania wysokiej wydajności (HPC) swoim nowym produktem: Windows HPC Server 2008.
Microsoft podjął współpracę ze Stratusem w skali globalnej, w zakresie wspierania systemów wysokowydajnych systemów obliczeniowych HPC.
Udostępniona została przez Stratusa literatura na temat HPC, materiały White-Paper oraz Broszura.
VMworld is running in Las Vegas this week and VMware has announced some new and important products. Most importantly, they have announced VMware FT. You may wonder, how we differentiate and what VMware FT is all about. Here is all the new:
VMware FT Point – Counter Point
Introduction
Announcement Summary
VMware is announcing their latest version of ESX – VI 4.0 (formerly known as “K/L”).
This is the first major release since the June 2006 announcement of VI3 which propelled VMware to the top of the technology world. VI4 will be positioned as a major step in the evolution of the plug-and-play datacenter with the characteristics of capacity, scalability, self-optimization, and self-healing.
How does this impact Stratus?
The major impact to Stratus will be the unveiling of a new module called VMware FT (formerly known as “Record-Replay”). Expect to hear VMware sales reps using many terms we typically associate with Stratus products including “fault tolerant”, “continuous availability”, and “lock step”. In addition, ancillary conversation will include the product’s low overhead, its applicability for all applications, and its ability to seamlessly integrate into an existing VMware infrastructure. (These are not necessarily true)
Secondarily, VMware will also be announcing a suite of improvements to its HA failover clustering module consisting of improved monitoring/detection of faults and more granular failover capability including individual virtual machine failover. Improving VMware HA is a positive for Stratus because it provides an even stronger solution when combined with ftServer.
Stratus expects that (Release to Manufacturing) RTM of VI4 will occur in late CY/Q1 2009. Stratus plans to release VI4 on ftServer one month after VMware RTM.
Major Talking Points
1) VMware FT is Fault-Tolerant |
|
Expect to hear VMware say |
|
Through the use of software “lock-step” VMware replicates state to another virtual machine. When the primary VM encounters a failure, the secondary VM takes over with “zero downtime and zero data loss”. Voila!! Fault-Tolerance. The following URL is a link to last year’s demo at VMworld of Record/Replay: http://download3.vmware.com/vmworld/2007/webcast_9-13-07/files/lobby.html The section on record/replay begins 28:07 minutes into the presentation. |
|
Stratus Response |
|
In a narrow view of Fault Tolerance (as opposed to the Continuous Availability of ftServer) VMware’s FT can be considered fault tolerant. But as the availability experts for over 28 years, we understand that FT is more then just initials. While VMware FT will protect against unplanned data loss, it does not provide the sophisticated data protection features found on the Stratus ftServer. Ultimately, as an untested, first-generation product, your customers should be wary about deploying their most mission critical applications on such a product. |
|
Reality Check |
|
Feature |
Reality |
Offers protection against data loss |
Yes |
Provides instantaneous take-over upon outage |
No |
Provides automated failure diagnosis |
No |
Protects against transient errors |
No |
Questions to Ask |
|
|
|
2) The performance of VMware FT has not been an issue |
|
Expect to hear VMware say |
|
While there may be some “performance overhead” associated with software lockstep, customers have been willing to increase their configurations in order to take advantage of this exciting feature. |
|
Stratus Response |
|
Any software lockstep solution by its very nature places additional demands upon the CPU, network, and I/O resources of the systems on which it runs. Compounding this problem, VMware FT restricts a virtual machine to the use of a single processor core. Consider that!! Not only is the product limiting the resources that can be used, it is actually INCREASING the load on the CPU resource. It is in fact counter-productive to limit an application to a single core and then increase the use of system resources. Another, and perhaps more significant consequence of software lock step is the impact on application response time. Ultimately, the roundtrip time required of such tasks as replication, heartbeat, and replay adds to the amount of time required to process a transaction and can not be solved by simply over-configuring the system with additional resources. Examples of applications that are sensitive to latency include: NFS, Windows File sharing, anything that doesn’t perform well over a LAN, and database because of the frequent writing to logfiles. |
|
Reality Check |
|
Feature |
Reality |
Runs with minimal impact to system resources |
Depends |
Has minimal performance impact to applications |
Depends |
Can run on systems without increasing the configuration |
Depends |
Questions to Ask |
|
|
|
3) VMware FT is suitable for all applications |
|
Expect to hear VMware say |
|
VMware FT is transparent to the application and as such is can bring fault-tolerance to virtually any application. |
|
Stratus Response |
|
The sweet spot for virtualization up to now has been those applications that are operating well below normal load and would benefit from consolidation onto a single server. While these applications are the most prevalent in virtualized environments, they are conversely the least likely to require fault-tolerance. By their very nature, applications that require extraordinary levels of protection are often among the most resource intensive. Will a product that is limited to the performance of a single core match the requirements of such an environment? Furthermore, there are inherent requirements for redundancy, networks, and storage in the architecture of VMware FT such that it may require the modification of the CONFIGURATION although the application itself does not require any modification. |
|
Reality Check |
|
Feature |
Reality |
Applications can run unmodified |
Yes |
VMware FT is suitable for all application environments |
No |
Questions to Ask |
|
|
|
4) VMware FT is easy to use |
|
Expect to hear VMware say |
|
VMware FT is fully integrated with VI4. It is simple and almost effortless to deploy and manage VMware’s new “one click fault-tolerance” |
|
Stratus Response |
|
A VMware FT deployment requires two (2) servers, each configured with a copy of VI4 plus duplicate copies of all the guest operating systems and applications that require protection (does this remind you of an HA cluster?). |
|
Reality Check |
|
Feature |
Reality |
Runs on industry standard hardware with no modifications |
Yes |
Can be deployed on a single platform |
No |
Requires a single copy of VMware |
No |
Requires a single copy of the application |
No |
Can be deployed with a minimum of planning |
No |
Questions to Ask |
|
|
|
5) VMware FT runs on any hardware |
|
Expect to hear VMware say |
|
VMware FT runs on industry standard hardware. Simply configure VMware FT and a partner VM will be provisioned for it on another server. |
|
Stratus Response |
|
While virtualization abstracts a great deal of the hardware characteristics, and thus provides superior solutions compared to traditional HA cluster and DR products, care must be taken to insure what VMware refers to as “CPU Compatibility”. VMware FT leverages VMotion technology to migrate a VM from one system to another. VMotion requires that systems be from the same CPU vendor, the same CPU family and even that the two CPU’s have compatible instructions sets within the CPU family. For example, the Cloverton processor used in the ftServer 6200 and the Woodcrest processor used in the ftServer 6210 are the same CPU vendor and family but do not have compatible instructions sets and are thus not suitable for VMotion. The requirements for compatible instruction sets for VMware FT is even more restrictive than for VMotion, and further limits the hardware pool that can be configured as a secondary VM. |
|
Reality Check |
|
Feature |
Reality |
Runs on industry standard hardware |
Yes |
Configurations do not need to match |
Restrictions |
Isolates and diagnoses hardware problems |
Limited |
Questions to Ask |
|
|
|
W związku z wątpliwościami wynikającymi ze stosowania technologii wirtualizacji VMware przy wykorzystaniu standardowych platform serwerowych takich jak np. balde’y, pojawiają się najczęściej dwa pytania o argumentację za architekturą ftServer.
- Niektórzy klienci twierdzą, że systemy ftServer wykorzystujące technologię VMware zapewniają jedynie dwukrotną nadmiarowość, a dzięki zainstalowaniu oprogramowania VMware na x serwerach blade można uzyskać x-krotną nadmiarowość przy zachowaniu bardzo niskiej ceny. Jak odpowiadać na taki argument?
- Niektórzy klienci uważają, że jeden klaster z oprogramowaniem Oracle RAC zapewnia im dwukrotnie większą wydajność, ponieważ oba węzły działają w tym samym czasie, a w razie awarii jednego z nich drugi nadal działa bez problemów. W takiej formie jest to rozwiązanie podobne do serwera ftServer, ale z dwoma aktywnymi obudowami. Jak odpowiedzieć na taki argument? (To pytanie nie jest związane z VMware).
Podstawowym celem technologii VMware jest konsolidacja oraz zmniejszenie liczby serwerów fizycznych — inaczej niż w przypadku serwerów blade. Nie zmienia to faktu, że przy założeniu stałej mocy obliczeniowej serwery blade i serwery standardowe są tańsze od oferowanych rozwiązań ftServer.
Należy jednak przyjrzeć się nieco dokładniej uwarunkowaniom technicznym. Sama technologia VMware obejmuje dwa mechanizmy oferowane przez firmę VMware jako funkcje zwiększające dostępność.
VMotion
Pierwszy z nich to narzędzie VMotion, które pozwala uniknąć nieplanowanych przestojów. Jeśli na fizycznym serwerze z zainstalowanym oprogramowaniem VMware ESX wystąpi mniej istotny problem, który nie powoduje przerwania działania serwera, ale może być rozwiązany tylko w trakcie zaplanowanego przestoju, to należy skorzystać właśnie z funkcji VMotion. Funkcja ta pozwala przenieść działającą maszynę wirtualną z jednego fizycznego serwera ESX na drugi bez przerywania pracy. Z narzędzia tego można korzystać także na serwerach ftServer.
VMware HA
Drugie rozwiązanie to narzędzie VMware HA, umieszczone na konsoli VMC (Virtual Management Center) służącej do monitorowania serwerów fizycznych. Jeśli jeden z serwerów ulegnie awarii, konsola VMC restartuje na innym serwerze fizycznym wszystkie maszyny wirtualne, które wcześniej działały na uszkodzonym serwerze. Wiąże się to jednak z przerwaniem działania aplikacji na maszynach wirtualnych, a także wymaga ponownego uruchomienia wszystkich takich maszyn, co z kolei zajmuje sporo czasu. Ponadto ponowne uruchomienie aplikacji na nowym serwerze wymaga wycofania zmian wprowadzonych w bazie danych, co także jest procesem czasochłonnym. W związku z tym jeśli chwilowa przerwa w działaniu aplikacji (czas przerwy zależy od złożoności aplikacji, rozmiaru bazy danych itd.) nie jest dla klienta problemem, trudno będzie zachęcić go do zakupu rozwiązań zapewniających ciągłą dostępność. Jeśli jednak zatrzymanie aplikacji stanowi poważny problem, klient potrzebuje mechanizmu gwarantującego ciągłą dostępność.
W takim przypadku urządzenia ftServer mają wyraźną przewagę nad serwerami blade, ponieważ pozwalają korzystać ze wszystkich narzędzi platformy VMware — w tym VMotion i VMware HA — bez przerywania pracy aplikacji w przypadku awarii serwera fizycznego.
Bardziej naukowe uzasadnienie zastosowania serwera zapewniającego ciągłą dostępność w sytuacji, gdy kilka aplikacji jest skonsolidowanych na jednym serwerze.
Przyjmijmy dwa warianty:
I) n serwerów blade, przy czym na każdym z nich działa jedna aplikacja o dostępności p (gdzie n to liczba naturalna, a p to prawdopodobieństwo działania serwera lub aplikacji);
II) jeden serwer z n maszynami wirtualnymi, z których każda służy do uruchamiania jednej aplikacji, o dostępności q.
Prawdopodobieństwo P(X) działania n aplikacji w wariancie II) jest łatwe do obliczenia: P(X) = n * q, czyli innymi słowy dostępnych jest n * q aplikacji.
W przypadku wariantu I) zakładamy rozkład dwumianowy, w związku z czym prawdopodobieństwo
P(X) = ∑ k * n!/((n – k)! * k!) * (1 – p)n – k * pk = n * p.
Jeśli p i q są równe (co jest realistycznym założeniem, jeśli w obu wariantach stosuje się standardowe serwery blade i tradycyjne serwery), to prawdopodobieństwo jest w obu przypadkach takie samo, a zatem żadna z opcji nie wykazuje przewagi. Należy jednak pamiętać, że jeśli wszystkie aplikacje działają na jednym serwerze, awaria tego serwera ma znacznie poważniejsze skutki.
Inaczej mówiąc, zastosowanie prawdopodobieństwa jako jedynego miernika nie odzwierciedla w pełni sytuacji. Drastycznym przykładem może człowiek, który zanurza stopy w lodowatej wodzie, siedząc przy tym na bardzo gorącej powierzchni. Jeśli rozważyć to w ujęciu średniej matematycznej, człowiekowi temu powinno być umiarkowanie ciepło, jednak faktyczne doznania są o wiele mniej przyjemne. W matematyce do pomiaru skrajnych odchyleń od średniej służy wariancja V(X).
Wzór ma postać V(X) = P(X2) – (P(X))2, w związku z czym w przypadku wariantu I) uzyskujemy V(X) = n * p * (1 – p), a w przypadku
wariantu II) — V(X) = n2 * q * (1 – q).
Jeśli przyjmiemy raz jeszcze, że stosowane są standardowe serwery, a przez to wartości p i q są sobie równe, uzyskany wynik mówi nam, że uruchamianie wszystkich aplikacji na jednym serwerze jest n razy gorszym rozwiązaniem niż rozproszenie ich na n niezależnych serwerów. Wynik ten jest niekorzystny dla technologii VMware, ponieważ dowodzi, że konsolidacja niesie ze sobą ryzyko.
Na tym etapie wkraczają do gry serwery ftServer. Aby uzyskać tę samą wariancję V(X) — co w praktyce oznacza uniknięcie skrajnych skutków umieszczenia wszystkich aplikacji na tym samym serwerze — należy zwiększyć prawdopodobieństwo dostępności tego serwera.
Niech liczby wykażą.
W przypadku wariantu I) niech n = 50 a p = 99,9%, co daje V(X)= 50 * 0,999 * (1 – 0,999) = 0,04995.
Aby uzyskać tę samą wariancję V(X) w wariancie II), należy uzyskać prawdopodobieństwo dostępności q = 99,998%, co znakomicie pokrywa się z parametrami systemu ftServer!
To jest odpowiedź na pierwsze pytanie.
Argument przedstawiony w drugim pytaniu (tym niedotyczącym VMware) jest poniekąd słuszny z technicznego punktu widzenia. Dopóki oba serwery działają, obciążenie jest rozkładane równomiernie. W przypadku awarii jednego z serwerów działanie umieszczonej na nim aplikacji zostaje przerwane, w związku z czym musi ona zostać uruchomiona ponownie na drugim serwerze. Jeśli taka przerwa jest do przyjęcia (co raz jeszcze wskazuje, że nie ma faktycznej potrzeby zapewnienia ciągłej dostępności), to można tylko porównywać rozwiązania Oracle RAC i ftServer pod względem ceny, rozwiązanie o dużej dostępności firmy Oracle jest bardzo kosztowne, znacznie droższe niż system ftServer.