company_banner

Виртуальная машина SQL Server 2012 в Облаке — подключение

    В предыдущем посте мы создали в Azure виртуальную машину из галереи с предустановленной на ней пробной версией SQL Server 2012. К машине можно подключиться через удаленное соединение и выполнять административные задачи, в том числе администрировать SQL Server, т.к. на ней изначально имеются все необходимые компоненты, включая SSMS. С практической стороны наиболее распространенными являются не чисто облачные, а гибридные сценарии, когда данные частью хранятся в Облаке, а частью — в on-premise БД. Для их совместной обработки потребуется «сопрячь» свежесозданный SQL Server в Azure с on-premise SQL Server. Для начала было бы неплохо увидеть SQL Server на облачной виртуалке из локальной SSMS.

    blogs.technet.com/b/isv_team/archive/2012/10/08/3524623.aspx
    • –3
    • 2,8k
    • 4
    Microsoft
    404,29
    Microsoft — мировой лидер в области ПО и ИТ-услуг
    Поделиться публикацией

    Комментарии 4

      –1
      Какой смысл держать SQL Server на виртуалке, которая может в любой момент сломаться и потерять все сохраненные на ней данные, вместо того, чтобы использовать SQL Azure?
        0
        Смысл, в первую очередь, состоит в том, что SQL Server, установленный на виртуальной машине в Azure, это функционально такой же SQL Server, как и тот, что стоит у Вас локально той же версии и редакции, и он не имеет ограничений, присущих Windows Azure SQL Database, о которых говорилось выше (http://msdn.microsoft.com/ru-ru/library/windowsazure/ff394102.aspx). Что касается риска потери или поломки виртуалки, про который Вы говорите, в Облаке для обеспечения надежности и высокой доступности виртуальных машин применяются идейно аналогичные технологии, что и в случае SQL Azure. Для работы с данными в Azure существуют три подхода: blob, table и БД в SQL Azure — www.windowsazure.com/en-us/develop/net/fundamentals/intro-to-windows-azure/. “In all three cases, data is automatically replicated across three different computers in a Windows Azure datacenter to provide high availability”. Vhd виртуалки хранится в blob storage и автоматически копируется в две дополнительные реплики, как и облачная база. Это первое. Второе – возможность географической репликации между датацентрами (http://msdn.microsoft.com/ru-ru/library/windowsazure/jj156143.aspx), чтобы иметь возможность данным уцелеть, даже если в их первичный центр обработки попадет метеорит. «Как описано в записи блога Введение в географическую репликацию данных в хранилище Windows Azure (http://blogs.msdn.com/b/windowsazurestorage/archive/2011/09/15/introducing-geo-replication-for-windows-azure-storage.aspx), большие двоичные объекты и таблицы Windows Azure географически реплицируются между двумя центрами обработки данных, расположенными на определенном расстоянии друг от друга на одном континенте, обеспечивая дополнительную долговечность данных в случае крупной катастрофы без дополнительных затрат. При запуске виртуальной машины служба географической репликации хранилища Windows Azure реплицирует диски операционной системы и данных во второй географический регион по умолчанию». В третьих, Вы можете создавать availability sets для своих виртуальных машин, как описано здесь — www.windowsazure.com/en-us/manage/windows/common-tasks/manage-vm-availability/.
        0
        Vhd виртуалки хранится в blob storage и автоматически копируется в две дополнительные реплики, как и облачная база.

        Вы утверждаете, что локальный диск виртуалки после каждой записи на него дублируется в blob storage и реплицируется? Если нет, то сбой виртуальной машины приведет к потере данных.
          0
          Когда Вы создаете в Azure виртуалку, у Вас автоматически будет создан Storage Account (если не было до этого), в нем контейнер vhds, в нем как page blob хранится vhd Вашей виртуальной машины. Если бы vhd, как, впрочем, и база SQL Azure, реплицировался после каждого изменения, это вызвало бы значительные накладные расходы. Ведь даже обычный сервер баз данных до поры копит изменения в буферах и не отражает мгновенно каждую транзакцию в файле БД. Этим занимается фоновый процесс. Периодичность чекпойнтов зависит от recovery interval, кол-ва грязных страниц, нагрузки и т.д. Видимо, что-то похожее происходит в случае репликации дисков виртуальных машин. Как определяется интервал репликации vhd, я не знаю, но SLA гарантирует 99.9% доступности (http://www.windowsazure.com/en-us/support/legal/sla/).

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое