Database
 sql >> база данни >  >> RDS >> Database

Какво бих искал да видя в Amazon EC2 за управление на бази данни

Amazon EC2 (Amazon Elastic Compute Cloud) е страхотна платформа за облачни изчисления. По-голямата част от интернет работи на Amazon AWS – когато потребителите споменават „изчисления в облак“, те имплицитно говорят за Amazon AWS. Моята компания работи и управлява бази данни на AWS от няколко години и научихме много от нашия опит. Въпреки че AWS е лесна за стартиране и стартиране платформа, е изключително трудно да се изпълняват големи натоварвания с интензивни дискове на AWS. Не казвам, че това не може да бъде направено – обаче необходимото време и опит са извън повечето потребители. Ето няколко неща, които бих искал да видя в Amazon EC2, за да улесня стартирането на бази данни в AWS.

  1. Неефимерни локални дискове

    Мрежовият EBS е удобен за повечето работни натоварвания, но производителността е ужасна за натоварвания с тежки записи. Въвеждането на предвидени IOPS облекчава малко този проблем. Предоставените IOPS обаче са доста скъпи и разходите се увеличават, особено когато работите с голям клъстер с 10-20 машини. Като алтернатива ще бъде чудесно, ако тежките дискови натоварвания, като бази данни, могат да изтичат от локалния диск. Днес това не е опция, защото локалните дискове са „ефимерни“. Ако спрете и рестартирате вашата машина, тя може да се премести на друг хост и да загубите вашите локални данни. Това не е приемлив риск, дори когато има множество копия на данните.

  2. Евтин SSD

    Би било чудесно, ако Amazon може да вземе лист от книгата на DigitalOcean и да въведе евтини SSD за своите сървъри. Изчисленията от страна на сървъра бавно преминават към SSD и след няколко години SSD сървърите ще бъдат дефакто хранилище за вашите сървърни натоварвания. Днес Amazon предлага SSD, но те са доста скъпи и не са опция за повечето работни натоварвания. Освен това предлагането на SSD има същия „ефимерен“ проблем като локалните дискове.

  3. Межрегионални групи за сигурност

    Георазпределените клъстери са реалност на нашето време. Редица клиенти трябва да разположат сървъри в различни региони по множество причини, вариращи от наличност до разделяне. Единственият начин да защитите тези внедрявания днес е чрез използване на бял списък за IP адреси, който е изключително труден за поддържане. Групите за сигурност между региони значително ще облекчат тежестта за клиентите, внедряващи в множество региони. днес Amazon има много малко функционалност, която работи в различни региони. Наскоро те въведоха възможността за копиране на шаблони в различни региони, което е много полезно и се надявам да продължат да добавят повече функции, които са междурегионални.

  4. Синхронизирани моментни снимки в множество тома

    В някои от нашите по-големи клъстери от бази данни трябва да архивираме няколко сървъра едновременно. Например, в разделен MongoDB клъстер, трябва да архивирате последователно копие на всички фрагменти. Въпреки че днес има техники за това, всички те са доста космати и уязвими на провал. Идеален начин за архивиране на тези сървъри е да стартирате синхронизирана моментна снимка в няколко тома. Това ще осигури последователна моментна снимка на всички томове.

  5. По-добро управление на VPC

    Аз лично не харесвам идеята за излагане на производствени бази данни в интернет. Следователно аз съм голям фен на виртуалните частни облаци (VPC). Технологията е страхотна, но интерфейсът за управление е доста досаден. VPC и класическият EC2 са много сходни, докато не станат. В крайна сметка превключвате напред и назад между конзолата EC2 и конзолата VPC. След като управлявате 10+ сървъра, настоящата парадигма за управление натоварва много потребителя. Мисля, че има място за опростяване на концепциите и улесняване на управлението.

Както винаги, ако имате въпроси, не се колебайте да се свържете с нас [email protected].


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. SQL Azure:База данни XXXYYY на сървъра в момента не е налична

  2. Задаване на физическа готовност за активна защита на данните в архитектурата с един възел на RAC – част 2

  3. Как да работим с наследяване в ядрото на Entity Framework

  4. Преглед на поточно репликация за TimescaleDB

  5. Свързване към база данни с помощта на PHP