Javaslatok a tárhely szolgáltatóknak...

**dolcsi** · 2010-02-10, 08:58

Ttrisz eredeti hozzászólása

Csak én gondolom azt, hogy roppant szánalmas ez a beszélgetés itt, egy nyilvános fórumon?

Most őszintén, kit érdekel ez?

engem érdekel!
Ez a hozzászólásod viszont nem érdekel.

**abc** · 2010-02-10, 09:11

Mindketten védik az álláspontjukat, ez természetes. Azonban scs mint ügyfél, ha bénázik az szerintem nem egy szokatlan dolog. Ha úgy értenének hozzá nem lenne szükségük tárhelyszolgáltatóra.

Viszont sipi kijelentései hogy egymás között kinevették, ugratták egymás vele, fogadásokat kötöttek rá a kollégákkal hát nem biztos hogy jó fényt vet a cégre. Pláne hogy egy komoly látogatottságú fórumon tesz ilyet, amit több ezer potenciális ügyfél is olvas. Nem akarok belevau, ne értsetek félre de szerintem egy ilyen meddő vita sehova nem vezet.
üdv: abc

**rendszergazda** · 2010-02-10, 11:03

sipi eredeti hozzászólása

Amúgy pont azon a node-on amin scs is helyet foglalt 640db másik társával együtt a gazda OS-nek van 340GB SWAP területe erre a célra kijelölt SSD-n, és van 96GByte fizikai memória is.

OpenVZ alapú virtualizációt csináltok, vagy a Parallels Virtuozzo Containers-t használjátok? Ez a Paravirtualizációs technológia bevált nektek mint virtuális szerver termék?

Ha jól értem amit írtál, 96GB memórián osztozik 640 db. VE, így egy VE ~150MB memóriát használhat átlagban, ez praktikusan azt jelenti hogy a VE-k nagy része 128MB lenne? A SWAP-ot SSD meghajtóra tettétek, miért? Egy másik topicban épp azt veséztük ki szerveres kollégákkal, hogy az SSD techológia még nem túl üzembiztos, elég kevés írási ciklus az élettartamuk, így MTBF-ben meg a piszok drága szerver SSD-k sem jobbak, mint egy mezei desktop SATA2 diszk MTBF-be, swap-ra elég rizikós ilyet tenni, még megtükrözve is (hisz pont az írási ciklusok száma ami gond, ez meg a tükörnél egyformán pereg mintkét SSD esetében), ti mért döntöttetek mégis emellett, ill. milyen régen használjátok ezt a megoldást, és nem volt-e ezzel problémátok még?

sipi eredeti hozzászólása

A szerver nem ment el, mert nem tud elmenni, csak nem tudott több processzt indítani. Minden esetben elmondjuk, leírjuk, kommunikáljuk, hogy bizony egy szerver üzemeltetéshez kell némi linux/unix ismeret is.

Miért nem? UBC numproc limit miatt, vagy memórialimit/OOM miatt? Egy 256MB memóriával árult konténert hogy hoztok létre, milyen oomguarpages, vmguarpages és privvmpages paraméterekkel?

sipi eredeti hozzászólása

A kérdéses VPS-re a felhasználók (scs) pl nem konfigurált be tűzfalat, ezért volt eset rá, hogy az USA Védelmi Minisztériumból jött a levél, hogy az álatlunk delegált IP tartományból betörési kisérletet észleltek. Kiderűlt a gépet feltörték román IP-vel, és egyből mentek is tovább egy másik gépet feltörni. Ekkor valóban a kollégám lekapcsolta a szolgáltatást az ASzF-ben leírt feltételek alapján. Nem tudom pontosan, de gyanítom hogy ekkor volt hogy reggel felkelt scs és nem találta meg a honlapját.

Az ilyen USA védelmi minisztériumi leveleknek ne dőljetek be, hidd el, az USA védelmi minisztériumának elég jó a tűzfala és megvédi magát, másrész nem írogat emaileket kis magyar szolgáltatóknak, ezek mint hoax-ok.

Ezen felül az (open)VS paravitrualizáció esetében csak korlátozott netfilter (iptables) beállításora van lehetőség a konténerekből, ellenben szerver szinten globális szabályokat is előírhattok, így nem kell a felhasználókat teljesen védtelenül hagyni, ha maguk nem állítanak be tűzfalszabályokat. Pl. 25-ös kimenő port tiltás alapból, kivéve saját SMTP szerver felé, oda meg spamfilter, és máris alaposan meg lehet nehezíteni egy esetlegesen feltört vps-ről spammelni akaró cracker dolgát.

**sipi** · 2010-02-10, 15:21