In urma cu cateva zile (21-07-2010),  placa de baza a unui server a inceput sa raporteze erori la unul dintre procesoarele instalate. E vorba de un server foarte puternic, clasa enterprise  - Dell PowerEdge R610.

Defectiunea se manifesta prin restarturi aleatoare ale serverului. Mai exact, pe parcursul intregii zile am au fost 3 restart-uri, care a generat fiecare un downtime de cateva minute. Este prima situatie de acest gen pe care o intalnim la modelul R610, care in general se comporta impecabil.

Intamplator, masina respectiva era folosita ca nod al infrastructurii de VDS si, prin urmare, orice downtime ar fi afectat mai multi clienti. Trebuia sa rezolvam situatia cat mai repede si mai eficient, astfel incat clientii nostri sa fie afectati minim si sa nu se mai repete niciodata cazul.

Care este solutia noastra pentru aceste situatii?

Cea mai sigura si rapida cu putinta: inlocuim complet hardware-ul cu defectiuni. Informatia e complet transferata pe o alta masina, care e pusa in functiune imediat. Exista un downtime de cateva minute pentru fiecare client, dar ne asiguram astfel ca problema se rezolva imediat, inainte de investigare si este imposibil sa se repete.

In aceasta situatie, pentru ca serverul era functional, am inlocuit echipamentul intre orele 02:-00-03:00 a.m., cand traficul este foarte scazut si downtime-ul afecteaza minim clientii. Daca defectiunea ar fi fost mai grava si ar fi determinat oprirea serverului, acesta ar fi fost inlocuit pe loc.

De ce procedam astfel?

Avem pentru serviciile noastre de VDS si Servere Dedicate un SLA foarte strans – 99,9995% uptime, cel mai ridicat din industrie. In cazul in care apare o problema la o masina, situatie inevitabila atunci cand lucrezi cu mii de echipamente, nu ne permitem sa asteptam ca problema sa fie depistata si rezolvata. Asta ar putea dura cateva ore daca e o defectiune de hardware si, in acest timp, clientii nostri ar suferi.

Schimband cu totul hardware-ul ne asiguram ca datele clientilor nostri sunt accesibile, in siguranta si totul functioneaza perfect.  Asta e cel mai important. Ulterior, ne alocam tot timpul necesar pentru a face research in profunzime asupra situatiei si a stabili strategii de preventie.

Ne cerem scuze clientilor care au trecut prin inconvenienta respectiva. Va asiguram ca am facut si facem tot posibilul sa mentinem aceste situatii la minimum. Am povestit aceasta situatie tocmai ca sa stiti la ce va puteti astepta de la noi. Daca aveti feedback, il asteptam cu interes.

Fiecare companie din piata a implementat strategii de reducere a costurilor, dar nevoia pentru aplicatii de nivel enterprise este in continua crestere. O data cu definirea mai buna a noii paradigme SOA (Service Oriented Architecture) si a conceptului de intreprindere virtuala, rigorile de eficienta cresc din ce in ce mai mult.

Framework-ul Rails pare sa acopere nevoile generate de acest mediu. Iata cateva puncte cheie care il recomanda drept o solutie potrivita:

1. Time to market: Excelent. Poti sa creezi foarte rapid un prototip functional, pe care sa-l lansezi pe piata.
2. Costuri de dezvoltare: Destul de ridicat. Pentru ca developerii de RoR sunt rari deocamdata. In schimb este nevoie de o echipa mai mica pentru o aplicatie cu aceleasi functionalitati dezvoltata in java de exemplu.
3. Costul de mentinere in piata: Foarte mic – in cazul echipelor profesionale de developeri. Citeşte mai departe…

De aproape o saptamana ne confruntam cu un numar destul de mare de atacuri asupra unor clienti. In linii foarte mari, sunt flood-uri de cam 300.000 – 400.000 de pachete pe secunda. In acest moment avem cam 400.000 de pachete pe secunda catre un client, prin Romtelecom.

Capacitatea echipamentelor noastre e de aprox. 480.000.000 de pachete pe secunda, prin urmare, un astfel de atac nu reprezinta o problema. Pe de alta parte, atacurile se bazeaza, in general, pe reply-ul ack si pe o lista de ip-uri spoofate din toate clasele din Romania.

Practic, un flood asupra echipamentelor noastre are foarte putine sanse sa dea jos un server, dar atacul printr-un ip spoofat genereaza un raspuns automat din partea ip-urilor receptoare, care la randul lor transmit pachete utilizatorilor al caror ip a fost spoofat, dar care ar putea sa nu aiba vreo legatura cu noi sau clientii nostri. Suna complicat, nu?

Pe scurt, eforturile noastre si ale providerilor se concentreaza pe filtrarea pachetelor la iesirea din retea, nu la intrare. Pana intervin filtrele providerilor, reglarea se face in infrastructura noastra de border, pentru ca traficul de flood sa nu ajunga in retea si clientii sa nu fie afectati.

In timpul acestor atacuri, vizitatorii care acceseaza site-uri gazduite de noi ar trebui sa nu perceapa nici o diferenta. Daca link-urile catre provideri sunt congestionate, traficul este redirectionat prin alte retele si serviciile raman in picioare, indiferent de gravitatea atacurilor.

Un weathermap live al conexiunilor dintre noi si provideri nostrii poate fi vazut aici.

Alte informatii:

• Cel mai mare flood pe care l-am inregistrat pana acum a fost de 1.200.000 pachete si a cauzat caderea a patru dintre providerii nostrii – dar am mentinut disponibilitatea serviciilor prin cei ramasi.
• Cele mai distructive atacuri sunt cele facute de incepatori – “script kiddies”. Acestea nu sunt gandite sa atace un singur site si reusesc sa afecteze o parte insemnata din ceea ce inseamna reteua de internet din Romania. Aceste tipuri de atac (fara nici un sens ),  nu afecteaza hosterii sau clientii gazduiti ci doar utilizatorii normali de internet.

Openvz offers two options to connect your containers to the network: venet and veth. Read about the differences here

I’m doing this install on a centos 5.2 and ovzkernel 2.6.18.

You need bridge-utils package:

yum install bridge-utils


Adding a veth to a virtual machine is easy enough:

vzctl set 110 --netif_add eth0 --save


The problem is that nothing works actually out of the box, since the kernel doesn’t know what to do with the packages that get out of the virtual ethernet devices thus created (veth110.0 in our case). Citeşte mai departe…

Quick, quick as usual.

I’m doing this install on a dell 1850 which is a 64 bit platform, so in order to do it on other platforms don’t forget to select the apropiate architecture.
You need a keyboard and a monitor. (it’s a network install not network pxe install). You need either a dhcp service on your network or the ip address and gateway of your ISP.

1. Download your netinstall image and burn it on a cd:
go to: http://isoredirect.centos.org/centos/5/isos/x86_64/
i used ftp ftp://ftp.lug.ro
cd /centos/5.2/isos/x86_64/
ls

get CentOS-5.2-x86_64-netinstall.iso
you need to remember this mirror as it will be used doring the netinstall. Citeşte mai departe…

Quick, quick quick…

I’m doing this install on an old dell 1850, and did on a R300 and worked as well.
My architecture is for both platforms x86_64.

1. netinstall the host system (see this for more information): I use a barebones system (with nothing selected on the setup i.e. no gnome or any kind of x) Citeşte mai departe…

Here’s a post about an interesting behavioral design pattern called Visitor.

This design pattern should be applied for a stable collection of objects which implement the same interface.

What is it good for? We can use it in different scenarios. Let’s see only a few of them :

• You want to implement different operations on a collection of different objects, but you don’t want to change their classes.

• You want to collect data from a collection of unrelated classes and present that data in a comprehensive way.

• You want an easy way to recover the type of a certain object.

• You want the right method to be applied depending on the type of object received as a parameter.

How to do it?

1. Let’s say all the object in the heterogeneous collection of objects implement Element interface.
2. Create a Visitor base class with a visit(ElementXxx) method for each Element derived type.
3. Add an accept(Visitor) method to the Element hierarchy. The implementation in each Element derived class is always the same – accept( Visitor v ) { v.visit( this ); }.
4. Create a Visitor derived class for each “operation” to be performed on Element objects. visit()implementations will rely on the Element’s public interface.
5. The client creates Visitor objects and passes each to Element objects by calling accept().

For more information about this design pattern, read this post. It also contains C++ and java implementations examples.