VPSlink.com down da oltre 36 ore, migrazione fallita

[WizOfOz]

ovviamente la cattiva pubblicità con un down di 36 ore (pur su un provider lowcost, ricordiamolo), non manca purtroppo.

Tu interpreti il fatto di essere un low-cost come una scusante?

[Ste]

No interpreto il fatto di essere lowcost, a partire da 7 dollari al mese, col dire che non hai alcuna garanzia in caso di downtime, soprattutto nel contratto, così come per la perdita di dati. Per cui 36 ore di down sono tante anche per un lowcost, ma il fatto che appartenga a questa categoria è un chiaro motivo del perchè siano stati down tutte quelle ore: in altre compagnie non sarebbe accaduto o almeno avrebbero seguito i clienti anche durante il periodo di down.

[guest]

Be, non proprio.
I guasti tecnici si verificano in egual misura sia sui lowcost che sulle linee professionali. Se, banalmente, per risolvere un problema sono necessarie 10 ore, sia il lowcost che il professionale impiegherà 10 ore. Dipende molto dal problema.

E' vero che spesso il professionale ha una infrastruttura differente con maggiore tolleranza ai guasti, ma quasi sempre i tempi di ripristino (quelli reali, non quelli delle SLA) sono dati dal problema, non dalla fascia di mercato in cui si opera.

[WizOfOz]

secondo me la differenza sta nello staff a disposizione...
ci sono società lowcost che possono permettersi di avere una persona dedicata alla comunicazione e altre che non possono per ristrettezze del personale.

o può anche essere che non sapevano cosa dire

[guest]

Quoto il Mago.
In questi casi, puoi migliorare la comunicazione, ma se il problema è di difficile risoluzione, lo sarà anche per un provider professionale.

Dubito che i problemi prima di verificarsi si mettano a guardare il listino prezzi. "aaaahh sei lowcost? Bene bene, ora ci penso io "
Un po come i batteri di "siamo fatti così" Siamo fatti così - Wikipedia

[Valeriano Manassero]

E' vero che spesso il professionale ha una infrastruttura differente con maggiore tolleranza ai guasti, ma quasi sempre i tempi di ripristino (quelli reali, non quelli delle SLA) sono dati dal problema, non dalla fascia di mercato in cui si opera.

Quoto in toto, per esperienza personale, ho visto anche una bella sfilza di problemi su RackSpace che di certo non sono low-cost. E' normale che sia il tipo di problema a determinare i tempi di ripristino, però, su strutture adeguate, c'è comunicazione costante col cliente, eventuali rimborsi (che non saranno chissachè, ma qualcosa sono) e, soprattutto, personale in numero maggiore o più preparato che in certe rogne non si cacciano.
Non dico che nel low-cost ci siano dei tecnici babbei (anzi, il contrario), ma è chiaro che una struttura low-cost ha margini molto più bassi ed una migrazione come questa, probabilmente, è stata progettata da persone non preparate, anche perchè, esperienza insegna, quando fai migrazioni massive, le fai sempre, almeno in due step, ovvero, ne migri un numero minimo per verificare che tutto sia andato bene e procedi col resto, poco importa che sulla carta "nulla può andare storto" (sgratt sgratt ).

[guest]

E vero. (poi tanto lo sai, la pensiamo uguale su quasi tutto tranne che sulla frutta)

Quel che manca nei lowcost è il "valore aggiunto" ovvero il coccolare il cliente, tra cui tenere un report aggiornato in tempo reale in caso di problemi.
Ma questo è normale, devi tagliare, e si taglia sul valore aggiunto.

Poi al limite tagli anche sui tecnici, anzichè tenerne 10 perchè ne servono realmente 8, ne tieni 5.

Quello che però non capisco è come sia possibile che siano terminati gli inode. Il numero di inode lo setti in fase di creazione del filesystem, solitamente una migrazione del genere si fa tra due macchine clone o con la macchina di destinazione con capacità superiore a quella precedente.
Se han finito gli inode, un qualche tecnico o si è dimenticato di creare il FS con gli stessi parametri di quello precedente, oppure han messo troppi server sullo stesso nodo.

Ma poi, può capitare solo con VZ, perchè se usi Xen con VM appoggiate su LVM, ciascuna VM ha il suo filesystem, quindi non concorre ad occupare gli inode del nodo, su VZ invece mi pare di capire che il container è una 'directory' quindi si, concorre ad occupare inode.

[GrG]

Il problema è che hanno giustificato tutto con un problema di disco pieno e impossibilità di aggiungere inodes, il che ha fatto si, secondo loro, che non potessero scrivere le info di networking per far tornare online le macchine.....questa risposta è stata data a tutti, segno che qualcosa di più è successo oppure lo staff era alla sua prima migrazione (?).

Scusa? Hai per caso il comunicato originale?

Fa molto di "errore di creazione filesystem causa parametri errati in mkfs" e magari se ne sono accorti dopo aver migrato un tot di VPS, rendendo impossibile una ulteriore formattazione.

Naaaaaaaa. Se leggi nel forum gli utenti parlano di 16 core. Avranno ridotto ad un terzo il numero degli host, prima erano doppi quad, adesso son quadrupli quad. Ottimizzano i costi e fanno i fighi.

Se su un doppio dual ci mettevi 40 VPS sul quadruplo quad ce ne metti 100 sicure, forse 120.

Le prestazioni cadono, ma tanto fa figo dire "unico provider al mondo che ti da accesso a 16 core".

Linode spacca, negli ultimi 4 mesi il servizio è migliorato così tanto che hanno raddoppiato il numero di clienti, triplicato lo staff, hanno lanciato in europa, lanciati nuovi servizi che secondo me a breve lanceranno una fascia professionale.

E' vero che spesso il professionale ha una infrastruttura differente con maggiore tolleranza ai guasti, ma quasi sempre i tempi di ripristino (quelli reali, non quelli delle SLA) sono dati dal problema, non dalla fascia di mercato in cui si opera.

No Ale però è anche vero che se guadagni X puoi tenere lì una persona, se guadagni 6X tieni lì 6 persone, e questo influisce sui tempi di ripristino.

Quello che però non capisco è come sia possibile che siano terminati gli inode. Il numero di inode lo setti in fase di creazione del filesystem, solitamente una migrazione del genere si fa tra due macchine clone o con la macchina di destinazione con capacità superiore a quella precedente.

Io non ho capito cosa vuol dire che la mancanza di inodes ha portato problemi al networking.

[guest]

No Ale però è anche vero che se guadagni X puoi tenere lì una persona, se guadagni 6X tieni lì 6 persone, e questo influisce sui tempi di ripristino.

Non sempre.
Come esempio banale, se hai 30 dipendenti ed un filesystem da 10TB corrotto, il check del primo reboot impiegherà mezza giornata buona, che tu abbia 30 dipendenti o 1 cambia poco.

Intendevo questo.

Io non ho capito cosa vuol dire che la mancanza di inodes ha portato problemi al networking.

Da dove hai visto problemi al networking? Ste ha detto problemi agli inodes ed in una migrazione, l'unico caso in cui potresti aver problemi di numero di inode è solo e soltanto in caso di VZ ed un filesystem creato male. (oppure VZ con troppe VPS messe sul nodo senza fare bene i conti)

[GrG]

impossibilità di aggiungere inodes, il che ha fatto si, secondo loro, che non potessero scrivere le info di networking per far tornare online le macchine

E io mi chiedo: l'unico caso in cui un problema agli inodes tira giù TUTTI gli host è il caso in cui sto problema lo hai su un router, giusto?

Anche perchè, fosse stato un disco solo pieno, azzo fai a tirar giù tutta spry?

[guest]

E io mi chiedo: l'unico caso in cui un problema agli inodes tira giù TUTTI gli host è il caso in cui sto problema lo hai su un router, giusto?

Che nesso hanno gli inodes con il router?

Anche perchè, fosse stato un disco solo pieno, azzo fai a tirar giù tutta spry?

Ma che ne so io? Ste ha detto che hanno avuto un problema di inodes, ma io ci credo poco, anzi, non ci credo per niente.

O è andato giù solo 1 nodo, oppure han trovato una scusa un po traballante.

[Uno]

Ma poi, può capitare solo con VZ, perchè se usi Xen con VM appoggiate su LVM, ciascuna VM ha il suo filesystem, quindi non concorre ad occupare gli inode del nodo, su VZ invece mi pare di capire che il container è una 'directory' quindi si, concorre ad occupare inode.

Chi ti impedisce di usare LVM con VZ?

[guest]

Boh, credo nulla, facevo per dire.
Con Xen mi pare sia impossibile usare una directory come storage per i domU, mentre con VZ mi pare sia di default.

[GrG]

Che nesso hanno gli inodes con il router?

Vyatta intasato che vola giù-

[guest]

Non ha niente a che vedere gli inodes.
Gli inodes non li intasi con il traffico. sono i cluster del disco, li intasi solo e soltanto scrivendo dei dati e non ti si atterra un gateway, al massimo non scrivi più.