Oggi il servizio Bitrix24 non dispone di centinaia di gigabit di traffico, né di un enorme parco server (anche se, ovviamente, ce ne sono parecchi). Ma per molti clienti è lo strumento principale per lavorare in azienda, è una vera e propria applicazione business-critical. Pertanto, non c'è modo di cadere. E se l'incidente si fosse verificato, ma il servizio si fosse "ripristinato" così rapidamente che nessuno si fosse accorto di nulla? E come è possibile implementare il failover senza perdere la qualità del lavoro e il numero di client? Alexander Demidov, direttore dei servizi cloud di Bitrix24, ha parlato per il nostro blog di come si è evoluto il sistema di prenotazione nel corso dei 7 anni di esistenza del prodotto.
“Abbiamo lanciato Bitrix24 come SaaS 7 anni fa. La difficoltà principale era probabilmente la seguente: prima di essere lanciato pubblicamente come SaaS, questo prodotto esisteva semplicemente come soluzione in scatola. I clienti lo hanno acquistato da noi, lo hanno ospitato sui loro server, hanno creato un portale aziendale: una soluzione generale per la comunicazione dei dipendenti, l'archiviazione di file, la gestione delle attività, CRM, tutto qui. E nel 2012 abbiamo deciso di lanciarlo come SaaS, amministrandolo noi stessi, garantendo tolleranza agli errori e affidabilità. Abbiamo acquisito esperienza lungo il percorso, perché fino ad allora semplicemente non ne avevamo: eravamo solo produttori di software, non fornitori di servizi.
Quando abbiamo lanciato il servizio, abbiamo capito che la cosa più importante è garantire tolleranza ai guasti, affidabilità e disponibilità costante del servizio, perché se hai un semplice sito web ordinario, un negozio, per esempio, e ti cade addosso e rimane lì per un'ora, solo tu soffri, perdi ordini, perdi clienti, ma per il tuo cliente stesso questo non è molto critico per lui. Ovviamente era arrabbiato, ma è andato a comprarlo su un altro sito. E se questa è un'applicazione a cui è legato tutto il lavoro all'interno dell'azienda, le comunicazioni, le decisioni, allora la cosa più importante è conquistare la fiducia degli utenti, cioè non deluderli e non cadere. Perché tutto il lavoro può fermarsi se qualcosa dentro non funziona.
Bitrix.24 come SaaS
Abbiamo assemblato il primo prototipo un anno prima del lancio pubblico, nel 2011. L'abbiamo assemblato in circa una settimana, l'abbiamo guardato, fatto roteare: funzionava addirittura. Cioè potresti entrare nel modulo, inserire lì il nome del portale, si aprirà un nuovo portale e si creerà una base di utenti. Lo abbiamo esaminato, valutato il prodotto in linea di principio, lo abbiamo scartato e abbiamo continuato a perfezionarlo per un anno intero. Perché avevamo un grande compito: non volevamo creare due basi di codice diverse, non volevamo supportare un prodotto confezionato separato, soluzioni cloud separate: volevamo fare tutto all'interno di un unico codice.
Una tipica applicazione web a quel tempo era un server su cui veniva eseguito del codice PHP, un database mysql, i file venivano caricati, i documenti e le immagini venivano inseriti nella cartella di caricamento - beh, tutto funziona. Purtroppo, è impossibile avviare un servizio web estremamente stabile utilizzando questo. Lì, la cache distribuita non è supportata, la replica del database non è supportata.
Abbiamo formulato i requisiti: si tratta della capacità di essere ubicati in luoghi diversi, supportare la replica e, idealmente, essere ubicati in diversi data center distribuiti geograficamente. Separare la logica del prodotto e, di fatto, l'archiviazione dei dati. Essere in grado di scalare dinamicamente in base al carico e tollerare del tutto la statica. Da queste considerazioni, infatti, sono emersi i requisiti del prodotto, che abbiamo affinato nel corso dell'anno. Durante questo periodo, nella piattaforma, che si è rivelata unificata - per soluzioni boxed, per il nostro servizio - abbiamo fornito supporto per quelle cose di cui avevamo bisogno. Supporto per la replica mysql a livello del prodotto stesso: cioè lo sviluppatore che scrive il codice non pensa a come verranno distribuite le sue richieste, usa le nostre api, e noi sappiamo come distribuire correttamente le richieste di scrittura e lettura tra master e schiavi.
Abbiamo fornito supporto a livello di prodotto per vari archivi di oggetti cloud: Google Storage, Amazon S3, oltre al supporto per Swift stack aperto. Pertanto, questo è stato conveniente sia per noi come servizio che per gli sviluppatori che lavorano con una soluzione in pacchetto: se usano la nostra API solo per lavoro, non pensano a dove alla fine il file verrà salvato, localmente sul file system o nell'archivio dei file oggetto.
Di conseguenza, abbiamo deciso immediatamente di prenotare a livello dell'intero data center. Nel 2012 ci siamo lanciati interamente su Amazon AWS perché avevamo già esperienza con questa piattaforma: lì era ospitato il nostro sito web. Siamo stati attratti dal fatto che in ogni regione Amazon ha diverse zone di disponibilità - in effetti, (nella loro terminologia) diversi data center che sono più o meno indipendenti l'uno dall'altro e ci permettono di prenotare a livello di un intero data center: se fallisce improvvisamente, i database vengono replicati master-master, viene eseguito il backup dei server delle applicazioni Web e i dati statici vengono spostati nell'object storage s3. Il carico è bilanciato - a quel tempo da Amazon elb, ma poco dopo siamo arrivati ai nostri bilanciatori di carico, perché avevamo bisogno di una logica più complessa.
Ciò che volevano è ciò che hanno ottenuto...
Tutte le cose fondamentali che volevamo garantire - tolleranza agli errori dei server stessi, applicazioni web, database - tutto ha funzionato bene. Lo scenario più semplice: se una delle nostre applicazioni web fallisce, tutto è semplice: vengono disattivate dal bilanciamento.
Il bilanciatore (a quel tempo era l'elb di Amazon) contrassegnava le macchine fuori servizio come non integre e disattivava la distribuzione del carico su di esse. La scalabilità automatica di Amazon ha funzionato: quando il carico è cresciuto, nuove macchine sono state aggiunte al gruppo di scalabilità automatica, il carico è stato distribuito su nuove macchine: tutto andava bene. Con i nostri bilanciatori, la logica è più o meno la stessa: se succede qualcosa al server delle applicazioni, rimuoviamo le richieste da esso, eliminiamo queste macchine, ne avviamo di nuove e continuiamo a lavorare. Lo schema è leggermente cambiato nel corso degli anni, ma continua a funzionare: è semplice, comprensibile e non presenta difficoltà.
Lavoriamo in tutto il mondo, i picchi di carico dei clienti sono completamente diversi e, in modo amichevole, dovremmo essere in grado di eseguire determinati lavori di assistenza su qualsiasi componente del nostro sistema in qualsiasi momento, senza che i clienti se ne accorgano. Pertanto, abbiamo la possibilità di disattivare il database dal funzionamento, ridistribuendo il carico su un secondo data center.
Come funziona tutto? — Trasferiamo il traffico a un data center funzionante: se si verifica un incidente nel data center, quindi completamente, se questo è il nostro lavoro pianificato con un database, trasferiamo parte del traffico che serve questi clienti a un secondo data center, sospendendo esso replica. Se sono necessarie nuove macchine per le applicazioni web perché il carico sul secondo data center è aumentato, queste si avvieranno automaticamente. Terminiamo il lavoro, la replica viene ripristinata e restituiamo l'intero carico. Se dobbiamo eseguire il mirroring di parte del lavoro nel secondo DC, ad esempio installare aggiornamenti di sistema o modificare le impostazioni nel secondo database, in generale ripetiamo la stessa cosa, solo nella direzione opposta. E se si tratta di un incidente, allora facciamo tutto in modo banale: utilizziamo il meccanismo dei gestori di eventi nel sistema di monitoraggio. Se vengono attivati diversi controlli e lo stato diventa critico, eseguiamo questo gestore, un gestore che può eseguire questa o quella logica. Per ciascun database specifichiamo quale server è il failover e dove deve essere commutato il traffico se non è disponibile. Storicamente, usiamo nagios o alcune delle sue forchette in una forma o nell'altra. In linea di principio, meccanismi simili esistono in quasi tutti i sistemi di monitoraggio; per ora non utilizziamo nulla di più complesso, ma forse un giorno lo faremo. Ora il monitoraggio viene attivato dall'indisponibilità e ha la capacità di cambiare qualcosa.
Abbiamo prenotato tutto?
Abbiamo molti clienti dagli Stati Uniti, molti clienti dall'Europa, molti clienti più vicini all'Oriente: Giappone, Singapore e così via. Naturalmente, una quota enorme di clienti si trova in Russia. Cioè, il lavoro non è in una regione. Gli utenti desiderano una risposta rapida, esistono requisiti per conformarsi a varie leggi locali e all'interno di ciascuna regione riserviamo due data center, inoltre ci sono alcuni servizi aggiuntivi che, ancora una volta, è conveniente collocare all'interno di una regione - per i clienti che si trovano in questa regione sta funzionando. Gestori REST, server di autorizzazione, sono meno critici per il funzionamento del client nel suo insieme, puoi passare da loro con un piccolo ritardo accettabile, ma non vuoi reinventare la ruota su come monitorarli e cosa fare con loro. Pertanto, stiamo cercando di utilizzare al massimo le soluzioni esistenti, piuttosto che sviluppare qualche tipo di competenza in prodotti aggiuntivi. E da qualche parte utilizziamo banalmente il passaggio a livello DNS e determiniamo la vivacità del servizio tramite lo stesso DNS. Amazon ha un servizio Route 53, ma non è solo un DNS in cui puoi inserire voci e basta: è molto più flessibile e conveniente. Attraverso di esso puoi creare servizi geo-distribuiti con geolocalizzazione, quando lo usi per determinare da dove proviene il cliente e fornirgli determinati record - con il suo aiuto puoi costruire architetture di failover. Gli stessi controlli di integrità sono configurati nella stessa Route 53, imposti gli endpoint da monitorare, imposti le metriche, imposti quali protocolli per determinare la "attività" del servizio: tcp, http, https; impostare la frequenza dei controlli che determinano se il servizio è attivo o meno. E nel DNS stesso specifichi cosa sarà primario, cosa sarà secondario, dove cambiare se il controllo dello stato viene attivato all'interno del percorso 53. Tutto questo può essere fatto con altri strumenti, ma perché è conveniente: lo impostiamo su una volta e poi non pensarci affatto a come facciamo i controlli, a come cambiamo: tutto funziona da solo.
Il primo "ma": come e con cosa prenotare la stessa linea 53? Chissà, e se gli succedesse qualcosa? Fortunatamente, non abbiamo mai calpestato questo rastrello, ma ancora una volta avrò una storia in anticipo sul motivo per cui pensavamo di dover ancora effettuare una prenotazione. Qui abbiamo preparato le cannucce in anticipo. Più volte al giorno eseguiamo uno scarico completo di tutte le zone che abbiamo sulla Route 53. L'API di Amazon ti consente di inviarli facilmente in JSON e disponiamo di diversi server di backup in cui lo convertiamo, lo carichiamo sotto forma di configurazioni e disponiamo, in parole povere, di una configurazione di backup. Se succede qualcosa, possiamo implementarlo rapidamente manualmente senza perdere i dati delle impostazioni DNS.
Secondo "ma": Cosa in questa immagine non è stato ancora prenotato? Il bilanciatore stesso! La nostra distribuzione dei clienti per regione è molto semplice. Abbiamo i domini bitrix24.ru, bitrix24.com, .de - ora ce ne sono 13 diversi, che operano in una varietà di zone. Siamo arrivati a quanto segue: ogni regione ha i propri bilanciatori. Ciò rende più conveniente la distribuzione tra regioni, a seconda di dove si trova il carico di punta sulla rete. Se si tratta di un guasto a livello di un singolo bilanciatore, viene semplicemente messo fuori servizio e rimosso dal DNS. Se si verifica qualche problema con un gruppo di bilanciatori, viene eseguito il backup su altri siti e il passaggio da uno all'altro avviene utilizzando lo stesso percorso53, poiché a causa del breve TTL, il passaggio avviene entro un massimo di 2, 3, 5 minuti .
Terzo "ma": Cosa non è ancora prenotato? S3, corretto. Quando abbiamo inserito i file che archiviamo per gli utenti in s3, credevamo sinceramente che fosse un perforante e non fosse necessario prenotare nulla lì. Ma la storia dimostra che le cose vanno diversamente. In generale, Amazon descrive S3 come un servizio fondamentale, perché Amazon stessa utilizza S3 per archiviare immagini di macchine, configurazioni, immagini AMI, istantanee... E se s3 si blocca, come è successo una volta in questi 7 anni, finché utilizziamo bitrix24, lo segue come un fan Ci sono un sacco di cose che accadono: incapacità di avviare macchine virtuali, errore API e così via.
E S3 può cadere: è successo una volta. Pertanto, siamo arrivati al seguente schema: qualche anno fa in Russia non esistevano strutture pubbliche serie per lo stoccaggio di oggetti, e abbiamo considerato la possibilità di fare qualcosa di nostro... Fortunatamente, non abbiamo iniziato a farlo, perché avremmo abbiamo approfondito le competenze che non abbiamo e probabilmente faremmo un pasticcio. Ora Mail.ru ha spazio di archiviazione compatibile con s3, Yandex ce l'ha e numerosi altri provider ce l'hanno. Alla fine siamo giunti all'idea che volevamo avere, in primo luogo, il backup e, in secondo luogo, la possibilità di lavorare con copie locali. Nello specifico per la regione russa, utilizziamo il servizio Mail.ru Hotbox, che è compatibile API con s3. Non abbiamo avuto bisogno di modifiche importanti al codice all'interno dell'applicazione e abbiamo creato il seguente meccanismo: in s3 ci sono trigger che attivano la creazione/eliminazione di oggetti, Amazon ha un servizio chiamato Lambda - questo è un lancio di codice senza server che verrà eseguito proprio quando vengono attivati determinati trigger.
Lo abbiamo fatto in modo molto semplice: se il nostro trigger si attiva, eseguiamo il codice che copierà l'oggetto nello spazio di archiviazione di Mail.ru. Per avviare completamente il lavoro con copie locali dei dati, abbiamo anche bisogno della sincronizzazione inversa in modo che i clienti che si trovano nel segmento russo possano lavorare con lo spazio di archiviazione più vicino a loro. La posta sta per completare i trigger nel suo archivio: sarà possibile eseguire la sincronizzazione inversa a livello di infrastruttura, ma per ora lo stiamo facendo a livello del nostro codice. Se vediamo che un client ha pubblicato un file, a livello di codice inseriamo l'evento in una coda, lo elaboriamo ed eseguiamo la replica inversa. Perché è un male: se facciamo qualche tipo di lavoro con i nostri oggetti al di fuori del nostro prodotto, cioè con qualche mezzo esterno, non ne terremo conto. Pertanto, aspettiamo fino alla fine, quando compaiono i trigger a livello di archiviazione, in modo che, indipendentemente da dove eseguiamo il codice, l'oggetto che ci è arrivato venga copiato nella direzione opposta.
A livello di codice, registriamo entrambi gli storage per ciascun client: uno è considerato quello principale, l'altro è considerato quello di backup. Se tutto va bene, lavoriamo con lo storage più vicino a noi: cioè i nostri clienti che sono in Amazon, lavorano con S3, e quelli che lavorano in Russia, lavorano con Hotbox. Se il flag viene attivato, è necessario connettere il failover e trasferire i client su un altro archivio. Possiamo selezionare questa casella in modo indipendente per regione e cambiarla avanti e indietro. Non l’abbiamo ancora utilizzato in pratica, ma abbiamo previsto questo meccanismo e pensiamo che un giorno avremo bisogno proprio di questo interruttore e ci tornerà utile. Questo è già successo una volta.
Oh, e Amazon è scappata...
Questo aprile segna l'anniversario dell'inizio del blocco di Telegram in Russia. Il fornitore più colpito è Amazon. E, sfortunatamente, le aziende russe che lavoravano per il mondo intero hanno sofferto di più.
Se l'azienda è globale e la Russia rappresenta un segmento molto piccolo, il 3-5%, beh, in un modo o nell'altro, puoi sacrificarli.
Se questa è un'azienda puramente russa - sono sicuro che debba essere localizzata localmente - beh, sarà semplicemente conveniente per gli utenti stessi, comoda e ci saranno meno rischi.
E se si trattasse di un’azienda che opera a livello globale e ha un numero approssimativamente uguale di clienti dalla Russia e da qualche altra parte del mondo? La connettività dei segmenti è importante e devono funzionare tra loro in un modo o nell'altro.
Alla fine di marzo 2018, Roskomnadzor ha inviato una lettera ai maggiori operatori affermando che intendevano bloccare diversi milioni di IP di Amazon per bloccare... il messenger Zello. Grazie a questi stessi fornitori, sono riusciti a far trapelare la lettera a tutti e si è capito che il legame con Amazon avrebbe potuto andare in pezzi. Era venerdì, in preda al panico, siamo corsi dai nostri colleghi di server.ru, dicendo: "Amici, abbiamo bisogno di diversi server che non si troveranno in Russia, non in Amazon, ma, ad esempio, da qualche parte ad Amsterdam", per per poter almeno in qualche modo installare lì la nostra VPN e il nostro proxy per alcuni endpoint che non possiamo influenzare in alcun modo, ad esempio endpoint dello stesso s3 - non possiamo provare ad avviare un nuovo servizio e ottenere un IP diverso, dobbiamo ancora arrivarci. In pochi giorni abbiamo configurato questi server, li abbiamo messi in funzione e, in generale, ci siamo preparati per il momento in cui inizierà il blocco. È curioso che RKN, guardando il clamore e il panico, abbia detto: "No, non bloccheremo nulla adesso". (Ma questo è esattamente fino al momento in cui Telegram ha iniziato a essere bloccato.) Avendo impostato le funzionalità di bypass e rendendoci conto che il blocco non era stato introdotto, tuttavia, non abbiamo iniziato a risolvere l'intera questione. Sì, per ogni evenienza.
E nel 2019 viviamo ancora in condizioni di blocco. Ho guardato ieri sera: circa un milione di IP continuano ad essere bloccati. È vero, Amazon è stato sbloccato quasi completamente, al suo apice ha raggiunto i 20 milioni di indirizzi... In generale, la realtà è che potrebbe non esserci coerenza, buona coerenza. All'improvviso. Potrebbe non esistere per ragioni tecniche: incendi, escavatori, tutto il resto. O, come abbiamo visto, non del tutto tecnico. Pertanto, qualcuno di grande e grande, con i propri AS, può probabilmente gestirlo in altri modi: la connessione diretta e altre cose sono già al livello l2. Ma in una versione semplice, come la nostra o anche più piccola, puoi, per ogni evenienza, avere una ridondanza a livello di server sollevati altrove, configurati in anticipo VPN, proxy, con la possibilità di cambiare rapidamente la configurazione su di essi in quei segmenti che sono fondamentali per la tua connettività. Questo ci è tornato utile più di una volta, quando è iniziato il blocco di Amazon; nel peggiore dei casi, abbiamo consentito solo il traffico S3 attraverso di loro, ma gradualmente tutto questo è stato risolto.
Come prenotare... un intero fornitore?
Al momento non abbiamo uno scenario nel caso in cui l’intera Amazzonia dovesse crollare. Abbiamo uno scenario simile per la Russia. In Russia siamo stati ospitati da un fornitore, dal quale abbiamo scelto di avere diversi siti. E un anno fa abbiamo dovuto affrontare un problema: anche se si tratta di due data center, potrebbero esserci già problemi a livello di configurazione di rete del provider che influenzeranno comunque entrambi i data center. E potremmo non essere disponibili su entrambi i siti. Ovviamente è quello che è successo. Alla fine abbiamo riconsiderato l'architettura interna. Non è cambiato molto, ma per la Russia ora abbiamo due siti, che non provengono dallo stesso provider, ma da due diversi. Se uno fallisce, possiamo passare all’altro.
Ipoteticamente, per Amazon stiamo valutando la possibilità di prenotazione a livello di un altro fornitore; forse Google, forse qualcun altro... Ma finora abbiamo osservato in pratica che mentre Amazon ha incidenti a livello di una zona di disponibilità, gli incidenti a livello di un'intera regione sono piuttosto rari. Pertanto, teoricamente abbiamo l’idea di poter effettuare una prenotazione “Amazon non è Amazon”, ma in pratica non è ancora così.
Qualche parola sull'automazione
L’automazione è sempre necessaria? Qui è opportuno richiamare l'effetto Dunning-Kruger. Sull’asse “x” c’è la nostra conoscenza ed esperienza che acquisiamo, e sull’asse “y” c’è la fiducia nelle nostre azioni. All'inizio non sappiamo nulla e non ne siamo del tutto sicuri. Poi ne sappiamo un po' e diventiamo estremamente sicuri di sé: questo è il cosiddetto "picco della stupidità", ben illustrato dall'immagine "demenza e coraggio". Allora abbiamo imparato un po’ e siamo pronti per andare in battaglia. Poi commettiamo errori gravissimi e ci ritroviamo in una valle di disperazione, quando sembra che sappiamo qualcosa, ma in realtà non sappiamo molto. Poi, man mano che acquisiamo esperienza, diventiamo più sicuri.
La nostra logica riguardo ai vari passaggi automatici a determinati incidenti è molto ben descritta da questo grafico. Abbiamo iniziato: non sapevamo fare nulla, quasi tutto il lavoro veniva svolto a mano. Poi ci siamo resi conto che potevamo collegare l'automazione a tutto e dormire sonni tranquilli. E all’improvviso calpestiamo un mega-rastrello: viene attivato un falso positivo e scambiamo il traffico avanti e indietro quando, in senso buono, non avremmo dovuto farlo. Di conseguenza, la replicazione fallisce o qualcos’altro: questa è proprio la valle della disperazione. E poi arriviamo alla comprensione che dobbiamo affrontare tutto con saggezza. Cioè, ha senso fare affidamento sull'automazione, prevedendo la possibilità di falsi allarmi. Ma! se le conseguenze possono essere devastanti, allora è meglio lasciare il compito al turno di turno, ai tecnici di turno, che si accerteranno e monitoreranno che ci sia davvero un incidente, ed eseguiranno manualmente le azioni necessarie...
conclusione
Nel corso di 7 anni siamo passati dal fatto che quando qualcosa cade, c'è panico-panico, alla comprensione che i problemi non esistono, esistono solo compiti, devono - e possono - essere risolti. Quando costruisci un servizio, guardalo dall'alto, valuta tutti i rischi che possono verificarsi. Se li vedete subito, prevedete in anticipo la ridondanza e la possibilità di costruire un'infrastruttura tollerante ai guasti, perché qualsiasi punto che può guastarsi e portare all'inoperabilità del servizio lo farà sicuramente. E anche se ti sembra che alcuni elementi dell'infrastruttura non falliranno sicuramente, come lo stesso s3, tieni comunque presente che possono farlo. E almeno in teoria, abbi un'idea di cosa ne farai se dovesse succedere qualcosa. Avere un piano di gestione del rischio. Quando pensi di fare tutto automaticamente o manualmente, valuta i rischi: cosa succederebbe se l'automazione iniziasse a cambiare tutto? Ciò non porterà a una situazione ancora peggiore rispetto a un incidente? Forse da qualche parte è necessario utilizzare un ragionevole compromesso tra l'uso dell'automazione e la reazione dell'ingegnere di turno, che valuterà il quadro reale e capirà se è necessario cambiare qualcosa sul posto o "sì, ma non ora".
Un ragionevole compromesso tra perfezionismo e impegno reale, tempo, denaro che puoi spendere per lo schema che alla fine avrai.
Questo testo è una versione aggiornata e ampliata della relazione di Alexander Demidov alla conferenza .
Fonte: habr.com