Меню

Настройка vmware для sql сервера



Создаем базу данных под VMware vCenter

В данной заметке я покажу, опираясь на предыдущую в которой я показал, как установить СУБД (MS SQL Server 2008 R2), создать базу данных применительно к разворачиваемому в последствии VMware vCenter Server предоставляющую масштабируемую расширяемую платформу, которая служит основой для системы управления виртуализацией.

Заходим на сервер под доменной учетной записью — ekzorchik.

Подключаемся к оснастке управления средой SQL: «Пуск» – «Все программы» – «Microsoft SQL Server 2008 R2» – «Среда SQL Server Management Studio»

Далее авторизуемся с использование SQL авторизации под системной учётной записью с логином «sa» и паролем указанным в процессе развертывания СУБД.

Имя сервера вводим (local)

Проверка подлинности выбираем «Проверка подлинности SQL Server»

Имя входа: учётная запись sa

В случаем успеха, а он будет, если всё выше сделано правильно, результат должен соответствовать ниже предоставленному скриншоту ниже:

Теперь создаем базу данных:

Далее именуем создаваемую базу данных в пункте «Общие»:

Имя базы данных: vcenter_db -> используйте сокращенное название с целью вспоминания в последствие, для чего предназначена та или иная база данных.

Далее переходим на пункт «Параметры» и устанавливаем «Модель восстановление» из положения «Полная» в положение «Простая».

По окончании нажимаем кнопку «OK» для сохранения внесенных изменений.

Теперь создадим пользователя для созданной базы данных :

Для этого раскрываем параметр «Безопасность» — «Имена входа» и щелкаем правой кнопкой для вызова мастера «Создать имя входа».

Далее в диалоговом меню «Создание имени входа» предопределим следующие настройки , это Имя входа , т.е. логин пользователя, пароль для этого пользователя, базу данных и язык по умолчанию:

Далее откроем свойства созданного пользователя СУБД :

«Безопасность» — «Имя входа» — «Свойства»

И посредством вкладки «Сопоставление пользователей» наделим созданного пользователя правами доступа к база данных msdb и vcenter_db и схему по умолчанию dbo, не забыв предоставить роль: db_owner

На последнем шаге ограничим максимальный размер используемой памяти для сервера до 2048 Мб (или 2Gb).

Переходим на закладку «Память» и выставляем значение 2048 для максимального размера памяти.

Далее переходим на закладку «Безопасность» и активируем возможности аудита входа в положение «Все попытки входа».

Далее запускаем «Диспетчер конфигурации SQL Server».

«Пуск» – «Все программы» – «Microsoft SQL Server 2008 R2» – «Средства
настройки» – «Диспетчер конфигурации SQL Server»

Переходим на вкладку «IP-адреса» и правим значения:

Активен – положение «Да» — Указывает, активен ли выбранный IP-адрес

Динамические TCP-порты – значение «» — Использовать динамические порты

Далее нажимаем кнопку «Применить» после чего приложение уведомляет нас, что все внесенные изменения вступят в силу только после перезапуска службы. Нажимаем «ОК» и выходим из диспетчера Sql Server Configuration Manager.

, но для надежности можно и перезапустить саму систему.

Пуск – Перезагрузка

Вот собственно и все процесс подготовки базы данных для разворачивания базы данных для приложения VMware vCenter. С уважением, ekzorchik.

Источник

Виртуализация vSphere, Hyper-V, XenServer и Red Hat

Более 5240 заметок о виртуализации и виртуальных машинах VMware, Microsoft, Citrix, Red Hat

VM Guru / News / Основные рекомендации по исполнению нагрузок Microsoft SQL Server в кластере хранилищ VMware vSAN.

Основные рекомендации по исполнению нагрузок Microsoft SQL Server в кластере хранилищ VMware vSAN.

Реклама:

Недавно мы писали о нативной поддержке Microsoft SQL Server в кластерах хранилищ VMware vSAN, а сегодня раскроем эту тему еще несколько глубже. Недавно VMware опубликовала полезный материал, содержащий основные рекомендации по исполнению нагрузок SQL Server в кластерах хранилищ VMware vSAN.

Надо понимать, что важно не только настроить серверы SQL, но и саму среду vSAN, в зависимости от характера ваших нагрузок (какие-то базы данных требуют высокой производительности, какие-то большой дисковой емкости и т.п.).

Давайте посмотрим, что это за базовые рекомендации:

1. Общие рекомендации.

  • Включайте дополнительный хост ESXi к результатам сайзинга по схеме n+1 на случай отказа диска, дисковой группы или всего хоста в целом.
  • Имейте хороший запас по пропускной способности сети для трафика vSAN, рекомендуется использовать 10G сеть с выделенной полосой для трафика синхронизации. Для All-Flash vSAN это обязательное требование. И не забывайте о резервировании каналов.
  • Имейте как минимум 2 дисковых группы на хост — это может увеличить полосу пропускания во многих случаях, а также обеспечивает лучшую отказоустойчивость.
  • Службы vSAN на уровне кластера:
    • vSAN Performance service (включен по умолчанию в vSAN 6.7) предоставляет метрики производительности в сторонние системы, такие как vRealize Operations, что позволяет эффективно мониторить и решать проблемы.
    • Вы можете использовать шифрование data at rest (FIPS 140-2 compliant), это не влияет на производительность по IOPS, но дает нагрузку на CPU, поэтому лучше использовать процессоры с поддержкой возможности AES-NI. Для end-to-end шифрования используйте туннели IPSEC. Если нужно зашифровать только отдельную БД, используйте SQL Server native encryption.
    • vSAN 6.7 поддерживает SCSI-3 persistent reservations для общих дисков при использовании SQL Server FCI. Для этого на уровне кластера надо включить службу vSAN iSCSI Target.

Настройте политики SPBM для данных SQL Server:

  • Политика Failures to tolerate (FTT): убедитесь, что выставлено как минимум значение 1, не используйте опцию «No data redundancy».
  • Политика Number of disk stripes per object: используйте значение по умолчанию (1) и подумайте о разделении данных между разными дисками VMDK, привязанными к разным контроллерам vSCSI.
  • Политика IOPS limit per object: vSAN 6.2 и более поздние версии имеют возможности QoS, которые могут ограничить IOPS, потребляемые дисковым объектам. Не используйте эту политику для задач, требовательных к нагрузкам. Эта фича используется, как правило, для операций резервного копирования и восстановления, чтобы предотвратить забитие полосы пропускания этими задачами.

2. Рекомендации для нагрузок Tier-1 (высоконагруженные OLTP-базы).

Как правило, такие нагрузки по вводу-выводу включают запросы с множественным позиционированием точек записи в базе данных, активность по сбросу грязных страниц кэша на диск, а также запись транзакционного лога. Размер операции ввода-вывода небольшой — в диапазоне 8K — 64K. Можно использовать бенчмарки TPC-E для воспроизведения паттернов OLTP-подобных нагрузок.

  • Рассмотрите возможность использования All-flash vSAN.
  • Используйте как минимум диски SAS SSD (а не SATA SSD) — у них больше глубина очереди. Также подумайте о технологии NVMe.
  • Отключайте дедупликацию и компрессию данных, которые включены в vSAN по умолчанию. Лучше использовать компрессию таблиц на уровне базы данных.
  • Для object space reservation установите «Thick provisioning» для всех VMDK с данными SQL Server и логами. Это позволит не натолкнуться на проблему нехватки места при использовании тонких дисков. Также в опциях SQL Server лучше установить настройку Perform maintenance tasks, чтобы инициализировать файлы с данными сразу же. Также выделите сразу место под лог БД, чтобы не натолкнуться на недостаток места в гостевой ОС, либо установите настройку его роста в ГБ, а не в процентах.
  • Не используйте IOPS limit for object.
  • Используйте RAID-1 mirroring и как минимум FTT=1 для для VMDK-дисков с данными и логом.
  • Если вы используете дополнительные методы отказоустойчивости, такие как Always On Availability Groups, то вам может потребоваться увеличить FTT. Делайте это не только с точки зрения доступности, но и с точки зрения производительности. Вы можете комбинировать отказоустойчивость Availability Groups на уровне приложения с отказоустойчивостью на уровне дисковой подсистемы.
  • Если вам требуется доступность SQL между площадками, можно использовать архитектуру растянутых кластеров (vSAN Stretched Cluster).
  • Подумайте о коммутаторах для трафика vSAN. Оптимально использовать кластеры all-NVMe vSAN, тогда операции ввода вывода будут быстро передаваться между дисковыми устройствами без участия физических контроллеров. Также лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода.

2. Рекомендации для нагрузок Tier-2 (высоконагруженные OLTP-базы).

Это нагрузки от которых не требуется экстремальной производительности, поэтому они должны быть эффективными с точки зрения стоимости. Тут актуальны следующие рекомендации:

Для гибридной среды vSAN (микс HDD+SSD) рекомендуется следующее:

  • Используйте несколько дисковых групп для увеличения пропускной способности.
  • Имейте как минимум 10% от емкости данных для пространства кэширования на SSD. Также рекомендуется использовать объем SSD-емкости как минимум в два раза больший, чем рабочий набор данных (working data set).
  • Используйте, по возможности, устройства SAS SSD вместо SATA SSD.

Если вы используете конфигурацию All-flash vSAN, то:

  • Используйте дедупликацию и компрессию, если у приложений нет высоких требований по операциям записи.
  • Если хотите экономить место и не требуется большой производительности, то используйте конфигурацию RAID 5/6 erasure coding, но для транзакционных логов используйте VMDK-диски, размещенные на RAID 1.
  • Для object space reservation установите «Thick provisioning» для всех VMDK с данными SQL Server и логами.

3. Нагрузки типа Data Warehouse и серверов отчетов (Reporting).

Для таких нагрузок характерен большой размер операции ввода-вывода, так как происходит запрос большого объема данных из БД. Критичной метрикой здесь является не IOPS, а пропускная способность (MB/s). Для генерации таких нагрузок могут быть использованы бенчмарки TPC-H.

Тут приводятся следующие рекомендации:

  • Для конфигураций All-flash лучше использовать NVMe SSD для хранилищ данных, это даст хорошую производительность по большим операциям чтения.
  • Для конфигураций All-flash в целях экономии места используйте RAID 5/6 для VMDK с данными БД.
  • Преаллоцируйте пространство для логов SQL Server, чтобы не натолкнуться на проблему нехватки места.
  • Не используйте IOPS limit for object, это может ограничить полосу пропускания.
  • Лучше использовать 10G-коммутаторы Enterprise-уровня с большими размерами буфера (non-shared), чтобы обеспечить работу с плотным потоком ввода-вывода и выдать хорошую пропускную способность.
Чтобы оставлять комментарии, вы должны быть зарегистрированы на сайте.

Зал Славы Рекламодателя
Все сайты о виртуализации:
12/11/2020: VMware vForum 2020 Online
12/11/2020: Veeam Live EMEA

Вебинары VMC о виртуализации:

Постер VMware vSphere PowerCLI 6.3:

Постер VMware ESXi 5.1:

Постер VMware Hands-on Labs 2015:

Постер VMware Platform Services Controller 6.0:

Постер VMware vCloud Networking:

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Постер VMware vCenter Server Appliance:

Порты и соединения VMware vSphere 6:

Порты и соединения VMware Horizon 7:

Порты и соединения VMware NSX:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

Постер Veeam Backup & Replication v8 for VMware:

Постер Microsoft Windows Server 2012 Hyper-V R2:

Источник

Оптимизация SQL Server в виртуальной среде

Всего лишь несколько лет назад об установке системы SQL Server на виртуальной машине не могло быть и речи. Другое дело сегодня. Установка SQL Server на виртуальных машинах стала обычной практикой во многих организациях, где используется SQL Server. Ниже публикуется семь рекомендаций для достижения оптимальных рабочих характеристик систем SQL Server, выполняемых на виртуальных машинах

1. Определяйте загрузку процессоров

Одна из проблем, которые возникают при выполнении SQL Server на виртуальной машине, состоит в перегрузке ядер физических процессоров. Иными словами, возникает ситуация, когда к одним и тем же ядрам физических процессоров обращается слишком много виртуальных машин. Это ведет к переключению задач на уровне хоста, что воспринимается клиентской операционной системой как задержка.

Пользователи платформы VMware vSphere (прежнее название VMware ESX) могут определять коэффициент загрузки процессоров с помощью команды esxtop. Обратите внимание на показатели CPU Load Average, отображающиеся в верхней строке. Эти показатели представляют среднюю загрузку процессоров на протяжении последних 5, 10 и 15 минут соответственно. Если значение средней загрузки 1, это означает, что процессоры хоста загружены полностью. Если же это значение превышает единицу, значит, справиться с нагрузками хост сможет лишь после оснащения дополнительными процессорами.

Кроме того, следует обратить внимание на показатели %USED. Они представляют выраженную в процентах долю нагрузки на процессоры, приходящуюся на соответствующее ядро. Если значение любого из этих показателей начнет регулярно выходить за порог в 75%, это будет свидетельствовать о том, что ядра физических процессоров перегружены и что серверу следовало бы добавить дополнительные ядра. Те, кто работает с программным продуктом VMware vCenter Server (прежнее название VMware VirtualCenter), могут использовать предоставляемые этим продуктом данные для анализа сведений о загрузке процессоров за предыдущий период.

Пользователям платформы Microsoft Hyper-V следует обращать внимание на те же категории данных. Хотя в продукте Hyper-V команды, подобные команде esxtop, не реализованы, администратор может определить выраженную в процентах нагрузку на процессоры для физического сервера с помощью утилиты Windows Performance Monitor. Нужно обращать внимание на следующие счетчики: Processor:% Processor Time и Processor:% User Time.

Если в сети установлен диспетчер виртуальных машин Microsoft System Center Virtual Machine Manager (VMM), вы можете использовать его для анализа тенденций. При отсутствии VMM анализ тенденций можно выполнять, экспортируя данные Performance Monitor в SQL Server или в другое приложение.

2. Отключайте Memory Balloon

И в системе vSphere, и в Hyper-V используются драйверы перераспределения памяти типа memory balloon, которые представляют собой программные драйверы, устанавливаемые на гостевых машинах. Они позволяют базовой операционной системе уменьшать физическую память гостевой операционной системы, чтобы эта память поступила в распоряжение другой виртуальной машины или базовой операционной системы. Когда базовая операционная система начинает испытывать недостаток памяти, она с помощью драйвера перераспределения памяти обращается к гостевой операционной системе с запросом на сброс некоторого количества данных из памяти, чтобы эту память можно было перераспределить. Это делается в автоматическом режиме и не требует вмешательства в работу гостевой операционной системы. На первый взгляд может показаться, что такая операция нежелательна, но на деле она может принести как вред, так и пользу; все зависит от того, какой объем памяти выделен гостевой системе, какой памятью располагает хост, на какой объем памяти претендует драйвер перераспределения памяти и от множества других факторов.

Некоторые пользователи считают, что на гостевых машинах, на которых выполняется SQL Server, драйвер memory balloon следует отключать. Но при его отключении главная машина может испытывать острую нехватку памяти, ибо у базовой операционной системы не будет возможности задействовать память гостевых операционных систем, вследствие чего базовая операционная система начнет переносить большие объемы памяти из физической оперативной памяти в файл подкачки базовой системы. Такая ситуация может возникнуть, к примеру, при запуске новых виртуальных машин или в случае, когда виртуальные машины переводятся с одного хоста на другой.

Если в компании VMware уже накоплен определенный опыт использования драйверов типа balloon memory, то Microsoft лишь недавно реализовала их в продукте Hyper-V. Чтобы эти драйверы могли функционировать в среде Hyper-V, базовая система должна работать под управлением операционной системы Windows Server 2008 R2 SP1 или более новой версии.

3. Память сервера не может быть доступна целиком

Одно из преимуществ платформы VMware состоит в ее способности предоставлять оперативную память для совместного использования в случае нехватки памяти при выполнении ресурсоемких задач. В продукте Hyper-V эта функция (dynamic memory sizing) была реализована в версии Server 2008 R2 SP1.

В виртуальных веб-серверах Windows и в серверах приложений доля памяти, которая может быть выделена для совместного использования, колеблется в пределах от 50 до 90%. Она определяется в зависимости от того, какое программное обеспечение выполняется и какие именно данные загружены в память. В серверах виртуальных баз данных значение этого показателя гораздо ниже — обычно оно составляет от 2 до 3%, если каждой виртуальной машине, выполняемой на таком сервере, выделяется оперативная память большого объема (64 Гбайт или более). Такое положение объясняется тем, что подавляющая часть этой памяти не может быть выделена для совместного использования. Чтобы иметь возможность выделять память для совместного использования, виртуальные серверы должны работать с одной и той же базой данных и в их память должны быть загружены одни и те же страницы. С учетом всех глобальных уникальных идентификаторов (GUIDS) и хэшей, хранимых в кэше процедур и в кэше буферов, мы можем смело заключить, что память, используемая ими, никогда не сможет быть выделена для совместного применения.

Совместное использование памяти — не такое уж великое подспорье, но, как бы то ни было, это полезная функция, и отключать ее не следует. Важно просто понять механизм совместного использования памяти, и тогда вы сможете делать достоверные предположения относительно того, при каких условиях возникает ситуация нехватки памяти. Если же вы исходите из того, что память сервера баз данных может быть выделена для совместного использования в полном объеме, созданные вами средства виртуализации будут далеки от совершенства.

4. Настройте хранилище

Хранилище данных — единственный элемент, при формировании которого возникает необходимость вновь обратиться к основным принципам, ибо при настройке хранилища для активно функционирующей виртуальной системы SQL Server следует применять те же подходы, что и при настройке хранилищ в физическом мире. Перечислим наиболее важные базовые положения, о которых нужно помнить.

Номера логических устройств, по-видимому, следует формировать из выделенной группы RAID, если ваш массив поддерживает выделенные группы RAID, или из пула FAST (Fully Automated Storage Tiering), если вы пользуетесь более современным массивом EMC. Количество операций чтения и записи, необходимых для обслуживания базы данных, не сокращается лишь потому, что база данных переносится с физического сервера на виртуальный. Более того, число операций чтения и записи может даже увеличиться, если возникнет необходимость в перераспределении памяти с помощью средств для совместного использования памяти или с помощью драйверов перераспределения памяти memory balloon.

Вам понадобится как минимум один диск для базы данных tempdb, диск для файлов данных пользовательских баз данных и диск для файлов журналов регистрации транзакций пользовательских баз данных. Будет еще лучше, если вы сумеете выделить по два диска для каждой пользовательской базы данных — один для файлов данных и один для файла журнала транзакций, — особенно если речь идет о серверах баз данных, работающих с большими нагрузками. Однако надо иметь в виду, что не все системы хранения данных выиграют от выделения двух отдельных дисков для каждой пользовательской базы данных; это зависит от того, каким образом спроектирована соответствующая база данных. За рекомендациями по организации массива обращайтесь к администратору хранилищ или к поставщику системы хранения данных.

Заметьте, что диски с операционными системами для виртуальных машин обычно настраиваются в соответствии со спецификациями RAID уровня 5 или 6, поскольку после установки операционной системы на дисках операционной системой, как правило, выполняется лишь небольшое число операций ввода-вывода по записи. Операционные системы в основном генерируют только ввод-вывод по чтению, когда в процессе загрузки в память приложений с диска считываются двоичные файлы.

5. Удаляйте из системы дубликаты данных

Если система хранения обеспечивает исключение дубликатов в оперативном режиме или «вживую», имейте в виду, что применение этой функции может способствовать общему повышению быстродействия среды. Кроме того, удаляя дубликаты с дисков средствами операционной системы, вы можете сэкономить большой объем дискового пространства, так как значительные фрагменты Windows на разных серверах идентичны. Поскольку виртуальные диски указывают на один и тот же физический блок, массиву достаточно загрузить этот блок в память всего один раз; в результате в кэше массива высвобождается немало места для других, более важных данных.

К примеру, для функционирования системы Server 2008 требуется порядка 20–30 Гбайт дискового пространства. При этом в память обычно загружается около 2 Гбайт данных. Поэтому, если вы оперируете 50 виртуальными машинами, в момент старта этих машин дисковый массив должен загрузить в память 100 Гбайт данных. Если же вы примените функцию исключения дубликатов, массиву придется загружать лишь от 2 до 3 Гбайт данных. Остальные виртуальные машины смогут впоследствии считывать эти блоки из кэша. Для реализации данной схемы потребуется несколько увеличить мощность процессоров, но полученная выгода вполне компенсирует немногочисленные обращения к процессору в массиве.

6. Отключите настройку «блокировка страниц в памяти»

Часто возникают споры о том, следует ли вообще использовать настройку «блокировка страниц в памяти» в системе SQL Server. В большинстве случаев — нет. Применительно к виртуальным машинам сказанное так же справедливо, как и по отношению к физическому серверу. В сущности, эта настройка может способствовать возникновению большего числа проблем именно в виртуальных машинах, так как она мешает работе драйвера перераспределения памяти memory balloon. Как я уже отмечал, этот драйвер может использовать память гостевой операционной системой, когда недостаток памяти испытывают другие компоненты системы. Если настройка «блокировка страниц в памяти» применена, гостевая операционная система не может возвратить эту память базовой операционной системе, вследствие чего последняя будет испытывать острую нехватку физической памяти.

7. Мониторинг

Мониторинг играет важнейшую роль в поддержании высокопроизводительной виртуальной среды. Администратор должен отслеживать показатели производительности, генерируемые виртуальными машинами (подобно тому, как отслеживаются эти показатели на физических системах) и физическим хостом, и сопоставлять эти два набора данных. Переходя от данных хоста к данным гостевых систем (или двигаясь в противоположном направлении), вы сможете с большей легкостью выявлять проблемы и прослеживать их влияние как на физическую, так и на виртуальную среду.

Выполнять мониторинг одного сервера Hyper-V совсем несложно, к тому же это можно делать бесплатно, если у вас установлена утилита Performance Monitor. Вы можете получать информацию о процессоре хоста (счетчик Processor:% Processor Time), об объеме используемой памяти (счетчик Memory: Available Mbytes), а также об операциях ввода-вывода (счетчики Physical Disk: Avg.Disk sec/Read и Physical Disk: Avg.Disk sec/Write).

Когда ваша система Hyper-V станет масштабнее, вы, вероятно, захотите приобрести инструментальные средства для осуществления мониторинга на уровне серверов. Выпускаемые корпорацией Microsoft диспетчер System Center Operations Manager и диспетчер виртуальных машин VMM дают возможность решать эти задачи. Продукт Operations Manager позволяет администратору осуществлять мониторинг рабочих кластеров Hyper-V. С его помощью также можно следить за работой виртуальных машин, что дает возможность сопоставлять два набора данных. VMM — средство управления рабочими кластерами Hyper-V, но его также можно использовать для мониторинга рабочих характеристик этих кластеров.

Следить за работой одного сервера vSphere можно с помощью бесплатно распространяемого инструментального средства VMware vClient. Недостаток этого средства заключается в том, что, будучи подключенным к одному виртуальному хосту, оно не фиксирует данные за прошедший период. Однако vCenter Server отслеживает исторические данные по рабочим характеристикам хостов и гостевых систем. С интервалом в несколько секунд это средство управления отслеживает десятки различных метрик и на основе полученных данных рассчитывает средние значения за час, за сутки, неделю, месяц и год для выполнения анализа долгосрочных тенденций.

Если вы используете обе платформы, Hyper-V и vSphere, вам, вероятно, понадобится единый интерфейс для осуществления мониторинга и управления. Если вы работаете с продуктом vCenter Server 3.5 или более новой версии (что необходимо при использовании серверов vSphere), а также с монитором VMM, у вас имеется возможность осуществлять мониторинг и управлять как платформой VMware, так и платформой Hyper-V с VMM. В этом случае вы будете отслеживать функционирование и управлять всей виртуальной средой из одного приложения.

Кроме того, на рынке представлены инструментальные средства для мониторинга виртуальных сред от независимых поставщиков, однако эти продукты, как правило, функционируют только на одном типе хост-платформ. К примеру, выпускаемое компанией Confio Software решение IgniteVM обеспечивает мониторинг рабочих характеристик базовой и гостевых машин в среде VMware.

Денни Черри (dcherry@awarenesstech.com) — старший администратор баз данных и архитектор в компании Awareness Technologies, более 10 лет занимается управлением системами SQL Server. Имеет несколько сертификатов Microsoft и звание Microsoft MVP

Поделитесь материалом с коллегами и друзьями

Источник

Читайте также:  Настройка raid на сервере asus

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector