È passato un po 'di tempo, ma abbiamo pensato che il nostro caso d'uso sarebbe stato utile ...
Primo + punto su AWS .
Abbiamo un server dedicato presso un host ben noto. È una grande specifica, e ho cercato di gestire i negozi Magento per anni. Abbiamo ottimizzato e giocato con la configurazione in un modo che non distruggerà i siti. Il nostro host non aveva installato APC (prima che io iniziassi), quindi l'hanno installato anche se li abbiamo pagati per costruire un Magento Server, abbattendo i nostri siti per 3 ore con una versione PHP non funzionante. Siamo riusciti a riavviarlo con un APC disabilitato.
in AWS Abbiamo una replica esatta di tutti i nostri AMI (NGINX, NGINX + Varnish, Control Server) seduti in attesa su AWS che possiamo accendere e giocare in qualsiasi momento. Possiamo clonare il volume EBS in base al quale i nostri dati Vhosts sono archiviati sulla mappa di alcuni IP sui nostri indirizzi IP interni VPC, agganciarli al server ed essere operativi in pochissimo tempo. Esegui il nostro TEST assicurati che tutto sia a posto, apporta le modifiche al sistema LIVE e spegni la replica fino a quando non è nuovamente necessario. A questo punto le modifiche che abbiamo apportato alla configurazione, cloniamo in una nuova versione AMI.
Secondo + punto per AWS . Abbiamo raggiunto un limite di indirizzi IP sul nostro host attuale. In AWS abbiamo un numero qualsiasi di indirizzi IP interni VPC e abbiamo assegnato al nostro account 20 IP esterni elastici che possiamo mappare su indirizzi IP interni. Le funzionalità di rete in AWS VPC sono assolutamente sorprendenti. È semplicemente irreale come abbiano impacchettato questo per amministratori di rete di basso livello. Ci sono voluti 3 giorni per ottenere alcuni nuovi indirizzi IP sul nostro host e aggiunti al loro firewall.
Qui è dove do ad AWS un altro +
I backup sul nostro attuale server dedicato sono solo un clone di una cartella contenuta in un deposito di backup. Fondamentalmente un disco montato. Un'unità montata disponibile solo per quel server. Quindi, nel caso di una grave interruzione, dovremmo ottenere una nuova configurazione del server, montare l'archivio di backup, installare e configurare il nostro nuovo server esattamente allo stesso modo (grande compito), quindi ricreare i dati. Il nostro host vanta 4 ore di giro per il nuovo hardware, ma questo non significa nulla per me. Sta ottenendo il backup della configurazione e dei siti.
La nostra attività offre soluzioni alle aziende per l'intero ciclo di vita del web. Consulenza, progettazione, SEO, supporto e manutenzione. Se avessimo avuto un'interruzione del nostro impegno, saremmo andati fuori mercato, perché sarebbero passati giorni prima che ci rimettessimo in piedi. Non possiamo avere questo scenario nemmeno sulla nostra mappa what what if. Non può proprio succedere.
In AWS attualmente abbiamo i nostri contenuti web su istanze AWS montate su volumi EBS a 750IOPS e una seconda istanza (quello che chiamiamo un server di controllo) che sincronizza i dati in un'altra zona di disponibilità nei tempi previsti e aggiorna un'istanza per l'ultima configurazione nel caso in cui è necessario avviare un'istanza da tale AMI. Sincronizza tutte le configurazioni NGINX, i file di installazione di PHP-FPM per questo.
Quindi ora abbiamo due serie di dati; un AMI che è un clone del server Web NGINX di produzione e una copia del contenuto della directory Vhosts con file di configurazione e Vhosts nel caso in cui avessimo bisogno di avviare un nuovo server.
È qui che AWS ottiene un altro + Il
nostro server dedicato lotta nelle ore di punta. Sì, eseguiamo Magento, quindi è leggermente diverso da alcune app. Abbiamo una configurazione del disco RAID da 32 GB Quad Core e a volte anche le interruzioni si verificano interruzioni quando un cliente invia una campagna di posta elettronica o due lo fanno contemporaneamente. Non possiamo fare praticamente nulla. Ha MySQL localmente, la sua memoria è ottimizzata per MYSQL ma i dischi sono scadenti.
In AWS eseguiamo 3 istanze CPU elevate. 2 server Web NGINX / PHP-FPM, oltre a un'istanza NGINX SSL + Varnish Cache. Abbiamo quindi un server Admin Magento più piccolo che ospita tutte le immagini e i media che vengono quindi mappati tramite CNAMES tramite Cloudfront. Si tratta di tutte le istanze riservate per contenere i costi.
Abbiamo quindi i nostri database in RDS su un'istanza di grandi dimensioni 2000IOPS a cui entrambi i server Web si connettono ad esso che prende istantanee ogni notte. Con un po 'di tempo morto (abbiamo pagine di manutenzione per i nostri negozi) possiamo ridimensionare gli IOPS e le dimensioni dell'istanza. La cosa migliore di RDS è che possiamo fare un'istantanea più recente e creare un nuovo DB per test e sviluppo. Quindi spegni. È semplicemente fantastico.
Utilizziamo Elastic Cache + e ora testiamo Redis per la gestione della cache per i server Web front-end. Ancora una volta possiamo ridimensionare su e giù.
Siamo in grado di aggiungere nuove istanze su richiesta di CPU ad alta CPU (clonando il nostro frontend NGINX) nel mix con un po 'di lavoro manuale per aiutarci a Natale e, se necessario, quando un cliente ci dice che invierà una vendita di 100.000 campagne di e-mail di vendita prodotti con il 75% di sconto.
Ora stiamo testando il nostro ridimensionamento automatico in Amazon e il modo in cui accendiamo i server, aggiungiamo indirizzi IP, aggiorniamo le configurazioni NGINX ecc. E iniziamo a lavorare senza problemi, ma poi anche per spegnere e spegnere il server durante i periodi di silenzio (vicino).
AWS + + Lo
spostamento dei dati sul nostro servizio dedicato interrompe il servizio. Copiando, Rsync MV ecc. Colpirà l'IO dei dischi che a sua volta rallenta i siti.
L'uso di volumi e snapshot in AWS è semplicissimo. Non ho davvero bisogno di dire nulla qui.
AWS +++++++
Gestione e controllo generali del server. In realtà non c'è davvero visibilità nel nostro server dedicato. È solo SSH e alcuni rapporti sul server davvero pessimi che il nostro host invia mensilmente.
AWS possiamo vedere statistiche che sebbene non siano completamente accurate ai miei occhi sulle prestazioni delle applicazioni, ti danno una buona idea su come funziona l'istanza reale. Abbiamo impostato gli allarmi per rilevare il problema.
Conclusione
* AWS vs Dedicated - Pure Power. * Per tutti i troll AWS non sto dicendo o nemmeno proverò a dire che AWS eseguirà uno dedicato con due Quad, carichi di memoria SSD ecc. Persino AWS non proverà a dirtelo. Ci sono cose che puoi fare per migliorare le prestazioni, l'ottimizzazione EBS, il provisioning IOPS e il ridimensionamento delle istanze, ma so che un'ossatura pura dedicata supererà le prestazioni.
AWS vs Dedicated: l'architettura per una soluzione adeguata
I server dedicati si sono seduti in un rack solitario da qualche parte, ma non lo taglierei per me. Questa non è una situazione reale o adatta come soluzione ai miei occhi quando si fornisce alle aziende una soluzione per gestire i propri negozi o siti.
Abbiamo la nostra intera rete di server in AWS VPC, possiamo espanderci, contrattare, vedere dove sono tutte le nostre risorse in un unico posto. Come soluzione non vorrei mai tornare a un server dedicato.
Se stavo gestendo un sito in grado di far fronte a una grave interruzione e potremmo aspettare di ricostruire un nuovo server con l'host, o se volessi usare due host o AWS come backup e spostare un sito se un dedicato è andato in crash, questo è il l'unico modo in cui lo farei. Questo di per sé è un problema che richiede tempo.
Costi
Il motivo per cui i server dedicati sono ora così economici è perché AWS offre modi economici per gestire il proprio mini data center, che è ciò per cui molti data center hanno utilizzato il premio. C'è un cambiamento nei prezzi e ora i data center devono usare tecniche di slagging contro AWS per vendere i loro servizi o gridare sulla potenza di Raw Server e sulla mancanza di alcuni tipi di istanze AWS.
Le persone che confrontano un server dedicato con un'istanza AWS dovrebbero davvero prendere in considerazione tutti i servizi extra che AWS offre intorno a quell'istanza del server e associarlo a un prezzo dedicato. Fammi espandere. Quando lasciarono e notificarono il contratto al nostro attuale host, dissero che questo era AWS, costi EBS di cattive prestazioni, ecc. Quindi abbiamo inviato una mappa della soluzione di ciò che volevamo.
- LAN privata con criteri di sicurezza / routing e firewall
- 20 indirizzi IP esterni, con la possibilità di rimappare tra i server al volo o tramite il pannello di controllo
- 4 server con 8 core ciascuno con 16 thread
- 32 GB di RAM
- Database Server con la capacità di fornire fino a 10000 IOPS ma generalmente circa 2000IOP
- Backup punta e clicca
- Nessun contratto o solo 12 mesi
Non solo non potevano fare tutto ciò, ma dicevano che se fossero stati in grado di fornire lo stack software per farlo, i nostri costi di installazione sarebbero stati di circa £ 10.000 più le commissioni mensili.
I server dedicati supereranno i cloud ma questo è ormai un ricordo del passato. Puoi vederlo nel marketing contro il cloud computing. Il cloud computing è la soluzione completa che collega le piccole imprese alla creazione di un proprio data center. Ai miei occhi e dopo aver impostato molte soluzioni AWS, AWS è la soluzione aziendale al momento
So che quando compro un'istanza AWS non è solo l'istanza, ma tutto il kit ad essa collegato. So che quando acquisto un server dedicato è davvero solo un server scaricato in un rack con un cavo collegato.
So che £ per £ un server dedicato sarà migliore di AWS, ma per i miei clienti e le esigenze di ACTUAL AWS supera di gran lunga le soluzioni dedicate