Когда вы запускаете SQL Server в облачных виртуальных машинах - будь то Amazon EC2, Google Compute Engine или Microsoft Azure VM, - есть несколько вещей, которые вам нужно обрабатывать иначе, чем на виртуальных машинах.

Быстрое совместное хранилище - действительно дорогое и все еще медленное. Если вы привыкли к флеш-памяти fancypants, вы будете горько разочарованы «быстрым» хранилищем в облаке. Возьмите Azure “Premium” Storage:

Приблизительно за 260 долл. США в месяц на премиум-диске P40 вы получаете 2 ТБ пространства с 7500 IOP и 250 МБ в секунду - это около 1/10 из IOP и половина скорости SSD на 300 т. Это касается не только Azure, любое облачное хранилище дорого и медленно работает для своей цены.

Таким образом, использование локальных твердотельных накопителей является неслыханным в локальных виртуальных машинах, но распространено в облаке. Попросите локальную VMware или администратора Hyper-V предоставить вам 1 ТБ локального SSD для TempDB у одной из гостевых систем, и они будут смотреть на вас, как будто вы с ума сошли. «Если я это сделаю, я не могу использовать vMotion гостевой системы от хоста до хоста! Это делает мое обслуживание ужасным!» В облаке это называется “эфемерным хранилищем”, и это настолько безумно быстро (по сравнению с общим хранилищем), что его трудно игнорировать. Не обязательно быть умным, чтобы использовать для локальных баз данных без большого планирования и защиты, - но для TempDB нет проблем.

Будьте готовы исправить плохой код с помощью оборудования. В облаке гораздо проще сказать: «Бросьте еще 8 ядер там» или «Дайте мне другой 64GB RAM» или «Мы забиваем TempDB, и нам действительно нужно что-то с более высокой задержкой для этого тома». При локальном размещении эти вещи входят в планирование и координацию между командами. В облаке это всего лишь вопрос бюджета: если менеджер хочет заплатить больше, то вы можете получить больше за считанные минуты. Но для того, чтобы сделать это изменение, вы действительно хотите перейти на новую виртуальную машину с необходимой мощностью, а затем переключиться на нее, а это значит …

Начните с зеркалирования или групп доступности. Локально вы можете располагать только одним SQL Server. Вы полагаете, что вряд ли когда-либо измените CPU/память/хранилище на существующей виртуальной машине, так зачем же планировать это? В облаке вы будете делать это чаще - и если строки подключения вашего приложения уже настроены для партнера по восстановлению дублирования базы данных или слушателя Always On Availability, это значит, что вы сможете сделать эти изменения с меньшим количеством требуемой работы от ваших прикладных команд.

Аварийное восстановление по требованию дешевле - но не быстрее. Вместо того, чтобы иметь кучу простаивающих мощных аппаратных средств, вы можете начать без виртуальных машин или небольшой виртуальной машины в вашем центре обработки данных DR. При приходе беды вы можете развернуть виртуальные машины, восстановить резервные копии и продолжать работу. Тем не менее вам по-прежнему нужен контрольный список для всего, что не входит в ваши резервные копии: считайте флаги трассировки, специальные настройки, логины (поскольку вы, вероятно, не планируете восстанавливать основную базу данных), связанные серверы и т. д. Дело в том, что люди не делают этого. Они думают, что они отложат планирование до тех пор, пока не наступит катастрофа - и в этот момент они шарят вокруг здания серверов, почесывая голову и догадываются об их конфигурации, о чем бы вы уже позаботились, если бы вы планировали использовать оборудование (или использовали что-то вроде VMware SRM для синхронизации виртуальных машин между центрами данных.)

Вы можете сэкономить деньги, взяв на себя долгосрочные обязательства. Мы много говорили о гибкости, способности двигать вашу виртуальную машину, работая с размерами дисков в любое время, но с Amazon и Azure вы можете неплохо сэкономить,, зарезервировав размеры ваших экземпляров на 1-3 года. Используйте экземпляры по требованию в течение первых нескольких месяцев, чтобы выяснить, как будет развиваться производительность, а затем через 3 месяца обсудите возможность придерживаться набора размеров экземпляров, зарезервировав их на год. Оговорки не привязаны к конкретным виртуальным машинам: вы можете передавать размеры между отделами. (Это одна из областей, в которой Google побивает всех - скидки на их использование в течение всего срока службы автоматически меняются со временем, никаких обязательств не требуется, но если вы хотите принять обязательство, у них также есть скидки).

No Comments