sql >> Database >  >> RDS >> Database

Wat ik graag zou willen zien in Amazon EC2 voor databasebeheer

Amazon EC2 (Amazon Elastic Compute Cloud) is een fantastisch cloud computing-platform. Een meerderheid van het internet draait op Amazon AWS - wanneer gebruikers verwijzen naar "cloud computing", hebben ze het impliciet over Amazon AWS. Mijn bedrijf runt en beheert al een paar jaar databases op AWS en we hebben veel geleerd van onze ervaringen. Hoewel AWS een eenvoudig platform is om aan de slag te gaan, is het buitengewoon moeilijk om grote schijfintensieve workloads op AWS uit te voeren. Ik zeg niet dat het niet kan, maar de tijd en expertise die nodig zijn, gaat de meeste gebruikers te boven. Hier zijn een paar dingen die ik graag zou willen zien in Amazon EC2 om het gemakkelijker te maken om databases op AWS uit te voeren.

  1. Niet-efemere lokale schijven

    Netwerk-gebaseerde EBS is handig voor de meeste workloads, maar de prestaties zijn verschrikkelijk voor schrijf-zware workloads. De introductie van ingerichte IOPS verzacht dit probleem een ​​beetje. Provisioned IOPS zijn echter vrij duur en de kosten lopen op, vooral wanneer u een groot cluster met 10-20 machines gebruikt. Als alternatief zou het geweldig zijn als zware schijfwerkbelastingen, zoals databases, van de lokale schijf zouden kunnen lopen. Het is vandaag geen optie omdat de lokale schijven "kortstondig" zijn. Als u uw machine stopt en opnieuw start, kan deze naar een andere host worden verplaatst en kunt u uw lokale gegevens kwijtraken. Dit is geen acceptabel risico, zelfs niet als er meerdere kopieën van gegevens zijn.

  2. Voordelige SSD

    Het zou geweldig zijn als Amazon een blad uit het boek van DigitalOcean kan halen en goedkope SSD's voor zijn servers kan introduceren. Server-side computing verschuift langzaam naar SSD en over een paar jaar zullen SSD-servers de feitelijke opslag zijn voor uw serverworkloads. Amazon biedt tegenwoordig wel SSD's aan, maar ze zijn vrij duur en geen optie voor de meeste workloads. Ook heeft het SSD-aanbod hetzelfde "kortstondige" probleem als lokale schijven.

  3. Regionale beveiligingsgroepen

    Geo-gedistribueerde clusters zijn een realiteit van onze tijd. Een aantal klanten moet om meerdere redenen servers in verschillende regio's implementeren, variërend van beschikbaarheid tot partitionering. De enige manier om deze implementaties tegenwoordig te beveiligen, is door een IP-whitelist te gebruiken die buitengewoon moeilijk te onderhouden is. Beveiligingsgroepen tussen regio's zullen de last aanzienlijk verlichten voor klanten die in meerdere regio's worden geïmplementeerd. vandaag heeft Amazon heel weinig functionaliteit die in verschillende regio's werkt. Ze hebben onlangs de mogelijkheid geïntroduceerd om sjablonen tussen regio's te kopiëren, wat erg handig is, en ik hoop dat ze meer functies blijven toevoegen die regiooverschrijdend zijn.

  4. Gesynchroniseerde snapshots over meerdere volumes

    In sommige van onze grotere databaseclusters moeten we meerdere servers tegelijk back-uppen. In een shard MongoDB-cluster moet u bijvoorbeeld een back-up maken van een consistente kopie van alle shards. Hoewel er tegenwoordig technieken zijn om dit te doen, zijn ze allemaal nogal harig en kwetsbaar voor mislukking. Een ideale manier om een ​​back-up van deze servers te maken, is door een gesynchroniseerde momentopname op verschillende volumes te starten. Dit zorgt voor een consistente momentopname over alle volumes.

  5. Beter VPC-beheer

    Persoonlijk houd ik niet van het idee om productiedatabases bloot te stellen aan het internet. Daarom ben ik een grote fan van Virtual Private Clouds (VPC). De technologie is geweldig, maar de beheerinterface is nogal vervelend. VPC en classic EC2 lijken erg op elkaar totdat ze dat niet zijn. Je schakelt uiteindelijk heen en weer tussen de EC2-console en de VPC-console. Zodra u meer dan 10 servers beheert, legt het huidige beheerparadigma een grote last op de gebruiker. Ik denk dat er ruimte is om de concepten te vereenvoudigen en het beheer gemakkelijker te maken.

Zoals altijd, als je vragen hebt, neem dan gerust contact met ons op via [email protected].


  1. Beste aanpak om tijdgedeelte van datetime in SQL Server te verwijderen

  2. Tips voor back-upbeheer voor TimescaleDB

  3. Opgeslagen T-SQL-procedure die meerdere id-waarden accepteert

  4. Opgeslagen Oracle-procedure:retourneer zowel de resultaatset als de out-parameters