нарушение аппаратной конфигурации что это

Ошибки конфигурации программ

Ошибки конфигурации программ — некорректная настройка программного обеспечения (избыточные права доступа, открытые порты или интерфейсы и т.п.), в результате которой компьютерная система или данные могут быть скомпрометированы. Конфигурирование под определенные платформы является важнейшим этапом внедрения любого программного продукта и условием успешности работы с ним; чем сложнее решение, тем выше риск ошибиться.

Отдельные личности или группы злоумышленников используют подобные нестыковки в собственных целях. Независимо от характера любой сбой приводит к ослаблению встроенных защитных механизмов и делает машину уязвимой перед хакерскими атаками.

Классификация ошибок конфигурации программ

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

Перечислим основные ошибки, которые могут использоваться преступниками для последующего взлома.

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

Объект воздействия

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

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

Причины возникновения ошибок конфигурации

Основные источники ошибок конфигурации многочисленны:

Некоторые проблемы возникают в результате комбинации совершенных ранее действий, которые по отдельности не приводят к появлению неполадок подобного рода.

Анализ риска появления ошибок конфигурации

От появления подобных ошибок никто не застрахован. Они могут возникнуть из-за неверных действий пользователей и после сбоев в работе аппаратной части. Хуже, что возникающие неполадки могут использоваться злоумышленниками для заражения компьютера.

Если при установке или запуске появилось сообщение об обнаруженной ошибке конфигурации (например, показанный выше «синий экран смерти»), необходимо выполнить следующие действия:

Если вышеперечисленные шаги не дали требуемого результата, можно попытаться переустановить приложение.

Важно внимательно изучать документацию к программным продуктам, особенно к комплексным решениям для корпоративной среды, и стараться не упускать потенциально опасные параметры, которые могли бы эксплуатироваться злоумышленниками. И домашнему пользователю, и администратору полезно знать, какая функциональность программного обеспечения избыточна для его задач, и отключать лишнее. Например, обычной рабочей станции совершенно не обязательно служить HTTP-сервером, поддерживая порт 80 открытым для внешних соединений.

Источник

Настройка параметров механизмов защиты и средств управления Secret Net 7

Настройка параметров механизмов защиты и средств управления Secret Net 7

В системе Secret Net информационная безопасность компьютеров обеспечивается механизмами защиты. Механизм защиты — совокупность настраиваемых программных средств, разграничивающих доступ к информационным ресурсам, а также осуществляющих контроль действий пользователей и регистрацию событий, связанных с информационной безопасностью.

Функции администратора безопасности

Функциональные возможности Secret Net позволяют администратору безопасности решать следующие задачи:

Для решения перечисленных и других задач администратор безопасности использует средства системы Secret Net и операционной системы (ОС) Windows.

Основными функциями администратора безопасности являются:

Параметры механизмов защиты и средства управления

Параметры механизмов защиты Secret Net в зависимости от места их хранения в системе и способа доступа к ним можно разделить на следующие группы:

Описание параметров объектов групповой политики

К общим параметрам безопасности ОС Windows добавляются параметры Secret Net. Эти параметры применяются на компьютере средствами групповых политик и действуют в рамках локальной политики безопасности. В системе Secret Net предусмотрены возможности настройки параметров групповых политик в стандартных оснастках ОС Windows и в программе оперативного управления.

В стандартных оснастках ОС Windows параметры Secret Net представлены в узле «Параметры безопасности» иерархии узлов групповой политики.

Для просмотра и изменения параметров в стандартных оснастках ОС Windows:

По умолчанию раздел «Параметры Secret Net» содержит следующие группы параметров:

Параметры настройки системы могут быть сгруппированы по принадлежности к защитным механизмам. Переключение режима группировки параметров осуществляется с помощью специальных кнопок панели инструментов или команд в меню «Вид» («По группам» и «По подсистемам»).

Для настройки параметров объектов политик безопасности:

На экране появится диалог настройки параметра.

Настройте параметры безопасности согласно приведенной таблице:

Для настройки событий, регистрируемых в журнале:

В правой части окна появится список регистрируемых событий.

Вход в систему в административном режиме

При штатном функционировании системы Secret Net вход любого пользователя компьютера, включая администратора, должен выполняться по одинаковым правилам, установленным соответствующими механизмами защиты. Во время загрузки компьютера перед входом пользователя система защиты проводит инициализацию компонентов и их функциональный контроль. После успешного проведения всех проверок вход в систему разрешается.

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

Примечание.

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

Для входа в систему в административном режиме:

Настройки параметров Secret Net, разделов: «Ключи пользователя», «Привилегии», «Регистрация событий», «Устройства», «Принтеры» — не требуют дополнительного конфигурирования.

Описание и настройка параметров пользователей

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

Примечание.

При копировании объектов «Пользователь» параметры Secret Net не копируются.

Настройка параметров пользователей осуществляется в стандартной оснастке ОС Windows «Управление компьютером».

Для просмотра и изменения параметров в стандартных оснастках ОС Windows:

В правой части окна появится список пользователей.

В левой части диалога расположена панель выбора групп параметров. Средства для настройки представлены в правой части диалога. Для перехода к нужной группе параметров выберите на панели соответствующую пиктограмму:

В текущей конфигурации ИС — настройки параметров Secret Net, разделов: «Идентификатор», «Криптоключ», «Доступ», «ПАК «Соболь» — не требуют дополнительного конфигурирования.

Атрибуты ресурсов

Параметры, относящиеся к атрибутам ресурсов файловой системы (файлов и каталогов), используются в механизмах управления доступом. Управление параметрами осуществляется с помощью расширения программы «Проводник».

Параметры настроек атрибутов ресурсов достаточны и не требуют дополнительных процедур настройки.

Описание механизмов контроля целостности (КЦ) и замкнутой программной среды (ЗПС).

Механизм контроля целостности (КЦ) предназначен для слежения за неизменностью содержимого ресурсов компьютера. Действие этого механизма основано на сравнении текущих значений контролируемых параметров проверяемых ресурсов и значений, принятых за эталон. Эталонные значения контролируемых параметров определяются или рассчитываются при настройке механизма. В процессе контроля при обнаружении несоответствия текущих и эталонных значений система оповещает администратора о нарушении целостности ресурсов и выполняет заданное при настройке действие, например, блокирует компьютер, на котором нарушение обнаружено.

Механизм замкнутой программной среды (ЗПС) предназначен для ограничения использования ПО на компьютере. Доступ разрешается только к тем программам, которые необходимы пользователям для работы. Для каждого пользователя определяется перечень ресурсов, в который входят разрешенные для запуска программы, библиотеки и сценарии. Попытки запуска других ресурсов блокируются, и в журнале безопасности регистрируются события несанкционированного доступа (НСД).

Настройка механизмов контроля целостности (КЦ) и замкнутой программной среды (ЗПС).

Для работы с программой управления КЦ-ЗПС пользователь должен входить в локальную группу администраторов компьютера.

Параметры механизмов контроля целостности и замкнутой программной среды настраиваются в программе «Контроль программ и данных», входящая в состав клиентского ПО системы Secret Net.

Для запуска программы нажмите кнопку «Пуск» и в меню вызова программ выберите команду «Код Безопасности | Secret Net | Контроль программ и данных».

В общем случае порядок настройки сводиться к выполнению следующих этапов:

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

Во время установки клиентского ПО системы Secret Net автоматически формируется локальная модель данных, в которую добавляются следующие задания:

Задания включают готовые задачи с ресурсами, сформированными по предопределенному списку. Для этих заданий устанавливаются связи с субъектом «Компьютер»;

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

Более детально порядок и правила администрирования и управления средством защиты информации Secret Net представлены в документации, входящей в состав комплекта поставки

Источник

Аппаратный сбой: в чем причина?

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

Однако аппаратный сбой все-таки возможен:

Несмотря на то, что эти электромеханические компоненты, как правило, очень надежны, такое повторяющиеся открытие и закрытие может в конечном итоге привести к поломке CD/DVD дисковода.

В 1999 году вирус CIH, также известный как «Чернобыль», нарушил работу нескольких сотен тысяч компьютеров, удалив данные в базовой системе ввода-вывода флэш-памяти (Flash BIOS) каждого компьютера.

Это сделало невозможным загрузку (или запуск) зараженных компьютеров, и ремонт был дорогостоящим:

Домашним пользователям пришлось обращаться в сервисный центр, чтобы перезаписать Flash BIOS и восстановить работоспособность компьютера.

Во многих ноутбуках микросхема Flash BIOS впаяна непосредственно в материнскую плату, поэтому в большинстве случаев стоимость ремонта превышала стоимость нового ноутбука.

Как защититься от вредоносных программ, которые приводят к аппаратному сбою

Установив эффективное антивирусное ПО, вы можете защитить свои компьютеры и мобильные устройства от всех типов вредоносных программ.

«Лаборатория Касперского» является признанным мировым лидером в разработке решений для защиты от вредоносных программ, которые могут обеспечить безопасность целого ряда устройств, в том числе:

Источник

Не секрет, что причины появления критических ошибок Windows, сопровождающихся «синим» экраном смерти, не всегда бывают очевидны. Название ошибки зачастую даёт лишь общее представление о неполадке, но не указывает на вызвавшую её конкретную причину. BAD SYSTEM CONFIG INFO в Windows 10 как раз является примером такой ошибки, которая может вызываться подключением новых устройств, установкой или обновлением драйверов, изменением настроек BIOS, повреждением загрузчика, сбоем в работе протокола NTLDR и прочими причинами так или иначе имеющими отношение к изменению конфигурации программной или аппаратной составляющей компьютера, на что, собственно, указывает название ошибки. Поэтому и подход к её устранению должен быть плановым и разносторонним.

Ошибка BAD SYSTEM CONFIG INFO в Windows 10

Загрузка последней удачной конфигурации

Так как появление ошибки BAD SYSTEM CONFIG INFO чаще всего бывает связано с изменением конфигурации, первое, что можно предпринять для устранения неполадки, это загрузить Windows с параметрами последней удачной конфигурации. К сожалению, опции, которая позволяла бы такую загрузку выполнить, в меню дополнительных вариантов загрузки Windows 10 больше нет, как нет и самого меню, вызываемого, если кто помнит, нажатием клавиши F8 сразу после включения компьютера. Для восстановления меню «Дополнительные варианты» загрузки» необходимо будет в рабочей системе (об этом нужно позаботиться раньше) запустить командную строку и выполнить команду bcdedit /set bootmenupolicy legacy.
Кроме того, если на ПК у вас включена опция «Быстрый старт», её также потребуется отключить, установив для параметра HiberbootEnabled значение 0 в ключе реестра HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Power. Это можно сделать как из работающей системы, так и из-под Live, например, из-под диска WinPE 10-8 Sergei Strelec, которому на нашем сайте посвящён целый цикл статей.

После проделанных манипуляций жмём при обычной загрузке F8 и выбираем в восстановленном меню «Дополнительные варианты» загрузки» опцию «Последняя удачная конфигурация». Если Windows 10 загрузится без ошибки, замечательно, можете отключить, если хотите, дополнительное меню командой bcdedit /set bootmenupolicy standard. Если проблема не решена, следуем дальнейшим инструкциям.
Примечание: даже если команда восстановления дополнительного меню будет выполнена успешно (есть вероятность получить ошибку «Ошибка при установке ссылки указанной записи»), не факт, что опция «Последняя удачная конфигурация» в нём появится. Мы пробовали этот трюк в Windows 11, меню успешно восстановилось, но без указанной опции.

Если ошибка возникла после замены оборудования

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

Выполните откат к предыдущей точке восстановления

Этот простой и действенный способ поможет устранить ошибку BAD SYSTEM CONFIG INFO, если она была вызвана изменением конфигурации системы через реестр или модификацией системных файлов. Загрузите компьютер с установочного диска, нажмите «Далее», затем Восстановления системы → Поиск и исправление неисправностей → Восстановление системы, выберите целевую ОС и проследуйте указаниям мастера восстановления. Заодно обратите также внимание на опцию «Восстановление при загрузке», ею вы можете воспользоваться с целью исключения повреждения загрузочных файлов.
Восстановите файл конфигурации Windows

Ошибка BAD SYSTEM CONFIG INFO может быть вызвана некорректными настройками дополнительных параметров конфигурации в утилите msconfig, например, изменением количества процессоров и выделенной памяти. Сброс этих настроек должен помочь восстановить нормальную загрузку операционной системы. Загрузитесь с установочного или спасательного диска в среду восстановления, запустите командную строку и выполните эти две команды:
bcdedit /deletevalue numproc
bcdedit /deletevalue truncatememory
Сброс системы к «заводским» настройкам

Не исключаем, что в запасе у вас есть и другие варианты решения этой проблемы, но, скорее всего, это будут дополнительные решения вроде проверки жёсткого диска и оперативной памяти на ошибки. Эффективность их сомнительна, если устранить ошибку не удастся, придётся идти на радикальные меры — сброс системы к изначальному состоянию или её полной переустановке.

Источник

1С в облаке: типичные ошибки при миграции и как их избежать

Привет, Хабр! Меня зовут Николай Араловец, я эксперт по облачным технологиям в #CloudMTS.
Периодически я общаюсь с заказчиками, которые либо уже перенесли 1С в облако самостоятельно, либо только собираются это сделать. У каждого такого заказчика возникают свои сложности:

Поясню сразу: материал будет полезен для компаний, которые планируют размещать базы данных и приложения 1С в облаке.

Пул задач зависит от того, на каком этапе переноса 1С в облако находится заказчик. Мы по отдельности рассмотрим проблемы тех, кто только собирается переезжать, и тех, кто уже разместил 1С на площадке провайдера.

Сложности при размещении 1С в виртуальной инфраструктуре

Сперва поговорим о нюансах, которые важно учесть при миграции в облако. В первую очередь, необходимо определиться с IaaS-провайдером и решить вопрос сайзинга.

Аппаратная конфигурация сервера в облаке

Для начала стоит узнать, какое физическое оборудование (compute node) использует сервис-провайдер и какие варианты его использования доступны. Для крупной инсталляции 1С (несколько сотен пользователей) оптимальным будет вариант размещения в выделенном вычислительном кластере, где используются серверы с высокочастотными процессорами (от 3 ГГц на ядро) и есть возможность выдать требуемый объем оперативной памяти на одну ВМ. На режим Intel Turbo Boost советую внимания не обращать: в виртуальной среде поведение гипервизора и ВМ на оборудовании с этой активированной опцией сильно отличается от поведения на bare-metal серверах.

Обязательно уточните, какие именно процессоры используются в серверах. Зачем это нужно? Например, в ряде конфигураций приложение и базу данных рекомендуется размещать на одной ВМ. Поэтому для нагруженной базы данных (MS SQL, PostgreSQL) может потребоваться определенное количество vCPU (более 4 vCPU) и оперативной памяти (от 64 Гб). Конечно, провайдер может предложить процессоры с тактовой частотой 3.8 ГГц на ядро — например, Intel® Xeon® Gold 5222. Однако у них всего по 4 ядра на сокет, поэтому есть риск, что у вас просто не получится выдать достаточное количество ядер и оперативной памяти машине, на которой будет работать связка «приложение 1С + СУБД». Очевидно, что это негативно отразится на общей производительности решения.

Хранилище в облаке

Как правило, наиболее популярный способ организации облачного хранилища у любого провайдера — общие хранилища (shared storage). Они могут быть реализованы на базе различных технологий — как проприетарных, так и с открытым кодом. Однако заказчик в любом случае должен понимать, что:

Для правильного сайзинга перед выбором вариантов где будут размещаться виртуальные машины соберите статистику по счетчикам дисковой подсистемы на серверах СУБД и базы данных на on-prem сайте. Это можно сделать самостоятельно — есть общедоступные инструменты для этого. Например, встроенный в Windows Server Performance Monitor со множеством счетчиков (disk, CPU, memory). Кроме этого я могу порекомендовать портал Live Optics — он предоставляет отчеты по нужным показателям производительности, в том числе и по дисковой подсистемы. Если возникнут сложности, не стесняйтесь обращаться к провайдеру: например, мы в #CloudMTS всегда готовы помочь со сбором нужных данных.

Безусловно, можно запросить выделенную конфигурацию аппаратного сервера с локальными NVMe дисками. Но будет ли она иметь отношение к облаку — вопрос.

При развертывании терминального сервера для доступа к 1С, производительность всей системы будет напрямую зависеть от доступности и пропускной способности канала между офисом/складом/магазином и облаком.

Тест Гилева может выдавать отличные результаты на виртуальной машине внутри облака. Но какой в них смысл, если время выполнения операций деградирует из-за проблем на стороне сети?

Чтобы избежать проблем, выбирайте провайдера с независимыми аплинками от двух поставщиков. Это можно сделать, например, проверив анонсы подсети провайдера через RIPE.

Далее подберите и как следует протестируйте ширину каналов между облаком и внутренней инфраструктурой (при больших расстояниях могут потребоваться корректировки TCP-параметров на уровне точек терминации трафика) и проверьте, что потери на канале не влияют на скорость.
Запрашивать сразу широкий канал смысла не имеет: по моему опыту, 9 из 10 заказчиков, которые запросили канал в 1 Гбит/c, не использовали его пропускную способность даже на 25%.

Механизмы отказоустойчивости

Доступность приложения и БД может быть реализована различными способами. На мой взгляд, наиболее правильный вариант — реализовать доступность на уровне приложения и/или БД с помощью кластеризации, always-on и прочих репликаций. Тем не менее, стоит уточнить у сервис-провайдера, какие механизмы отказоустойчивости присутствуют в облаке «by design» и как их можно использовать для повышения доступности.

В частности, это касается дисковой подсистемы. Ее простой может привести к длительной недоступности сервиса или потере данных. Например, если заказчик хранит данные на локальных дисках сервера без резервирования оборудования, при выходе сервера из строя, простой может измеряться часами или даже днями.

Другая ситуация — когда среда виртуализации не предоставляет механизмов автоматического перезапуска виртуальной машины на соседнем хосте в кластере, что также может увеличить время простоя. Сервис-провайдер, строящий свою инфраструктуру по определенным принципам, не будет скрывать ее параметры и особенности от заказчика. Наоборот, взаимодействие с технической службой провайдера позволит оптимальным образом использовать те возможности, которые он заложил в свою инфраструктуру. И сделать это еще на этапе внедрения.

Подводя итог, обозначу ключевые параметры облака, на которые необходимо обратить внимание при базовом сайзинге:

Проблемы с производительностью 1С в облаке

Мой опыт работы (8 лет на различных позициях) в облачном сервис-провайдере показывает: если заказчик переносит данные без проработанного сайзинга и учета специфики облачной инфраструктуры, то у него рано или поздно возникнут сложности. Давайте посмотрим, в чем прячется «корень зла» и как устранить уже появившиеся проблемы.

Ошибки сайзинга

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

Каждый современный гипервизор, развернутый на x86_64 архитектуре, представляет ресурсы (CPU, memory) в виде NUMA-нод, базирующихся на сокетах. Для однопоточных приложений — а 1С именно к таким и относится — накладные расходы на переключение контекста между сокетами могут значительно влиять на производительность.

На скриншоте ниже — результаты теста Гилева для двух виртуальных машин, размещенных на одном физическом сервере с 4 сокетами по 18 ядер. Одной виртуальной машине выделено 16 vCPU (1 vCPU = 1 сокет), второй — 42 vCPU (2 сокета по 21 vCPU). Результаты говорят сами за себя:

1. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 42 vCPU, 3 GHz (2 сокета, нарушение распределения по pNUMA), 64 Gb mem.

2. Тесты связки 1С 8.3 и MS SQL 2016, платформа Win2016, настройки BIOS штатные для облака, настройки ESXi штатные для облака; Конфигурация VM – 16 vCPU, 3 GHz (16 сокетов), 64 Gb mem.

Как я уже писал выше, не стесняйтесь консультироваться со специалистами сервис-провайдера по вопросам сайзинга и настроек виртуальных машин. Как показывает практика, они могут оказывать значительное влияние на работу приложения

Проблемы на канале связи

Тут сразу начну с примера из личной практики. Однажды к нам обратился заказчик, у которого резко упала производительность 1С: значительно увеличилось время выполнения определенных операций.

Разбирая тикет, наша служба поддержки проверила канал от офиса заказчика до его терминального сервера в облаке и выявила около 30% потерь. При этом они приходились на «последнюю милю», через которую подключен офис. После решения проблемы с каналом время выполнения операций вернулось к прежним значениям.

Особенности сайзинга 1С

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

Сайзинг 1С, в первую очередь, зависит от конфигурации приложения. Можно выделить три типовых конфигурации:

Два других варианта требуют детального подхода к тестам.

Любителям использовать для тестирования утилиту Crystal Disk Mark рекомендую брать одну из последних версий, 7.x, для тестов. В них есть возможность замерять значения в MB/s, IOPS и время отклика (latency) дисковой подсистемы для конкретного теста, а также менять параметры.

Рекомендации по сайзингу 1С в облаке

Перейдем к практическим рекомендациям, которые помогут при сайзинге.

Выбор аппаратных конфигураций под размещение сервисов 1С

От сервис-провайдера нужно получить следующие параметры:

В среде виртуализации есть ряд существенных отличий, которые значительно влияют на поведение этого режима. Например, его активация на уровне BIOS аппаратного сервера не означает, что тактовая частота виртуальных процессоров на уровне гостевой ОС будет отображаться как максимальная тактовая частота, заявленная для физического процессора. Более того, современные многоядерные процессоры не в состоянии выставить максимальную тактовую частоту для всех ядер одновременно, так как они ограничены параметром TDP (Thermal design power, «расчетная тепловая мощность»).

Приведу пример. На процессоре Xeon 6254 с базовой тактовой частотой 3.1 ГГц, заявленная максимальная тактовая частота — 4 ГГц. При активации режима TurboBoost на сервере с 4 процессорами 6254 и включенным режимом Power Management = High Performance, утилита esxtop без нагрузки показывает прирост не более 20% на каждое ядро. В действительности вы увидите реальный рост частоты на уровне виртуальной машины, только запустив ее на конфигурации с 1 vCPU, без какой либо сторонней нагрузки на аппаратном сервере, где размещена эта виртуальная машина. Даже если запустить эту же ВМ, например, в конфигурации с 8 vCPU, прирост частоты на каждый виртуальный процессор будет минимальным.

Сайзинг дисковой подсистемы

Ключевые показатели для СУБД — количество операций ввода/вывода в секунду и время отклика (IOPs и Latency). Оптимальным вариантом для сайзинга будет снятие замеров с текущей рабочей системы заказчика (например с помощью портала Live Optic). Расчет в этом случае будет базироваться на реальных показаниях.

Выделение локального сервера с NVMe дисками не имеет смысла. Такой подход не учитывает требования к отказоустойчивости и резервированию инфраструктуры и является избыточным в 99,9% случаев сайзинга, с которыми мы сталкивались. При необходимости мы как сервис-провайдер можем предоставить выделенный iSCSI LUN, выдаваемый напрямую в гостевую операционную систему, что позволяет снизить накладные расходы на виртуализацию.

Ширина канала

Прежде чем запрашивать 1 Гбит/с, убедитесь, что вы реально будете использовать хотя бы 20% от этой цифры. Или включите мониторинг — это позволит оптимизировать расходы в ходе эксплуатации.

Конфигурация виртуальных машин

Банальные, но важные советы:

Советы по работе с 1С в облаке

В завершение позволю себе привести ряд советов (не технических), которые помогут ускорить решение рассмотренных выше проблем.

1. Принимать активное участие в работе по тикетам, связанным с производительностью.

Конечно, можно просто написать запрос в службу поддержки и ожидать, что все проблемы будут устранены в соответствии с SLA. Однако тикеты, связанные с производительностью, почти невозможно решить без знания инфраструктуры заказчика.

На тикет заказчика, связанный с сетевыми проблемами, (пример был приведен выше в статье) у наших специалистов ушло около месяца. Этот срок можно сократить до нескольких дней — достаточно лишь контактировать с командой провайдера и следовать рекомендациям: например, использовать предлагаемые варианты диагностики.

2. Запрашивать у сервис-провайдера любую информацию, которая поможет ускорить работу сервиса.

Например, конфигурацию BIOS аппаратных серверов, на которых размещаются виртуальные машины. Настройки по умолчанию в облаке #CloudMTS таковы, что на процессорах с базовой тактовой частотой ядра в 3 ГГц при правильной конфигурации ВМ, заказчик, размещая 1С и MS SQL, получит в тесте Гилева не менее 33-35 «попугаев». Если вынести виртуальную машину в выделенный кластер, на такой же виртуальной машине при такой же частоте процессора их количество может вырасти уже до 42.

3. Постоянно анализировать быстродействие сервисов 1С в облаке

А не только когда появляется очевидная деградация. Делать это можно с помощью интегрального инструмента оценки APDEX, который даст существенно более объективную оценку быстродействия в сравнении с тестом Гилева (про APDEX можно почитать тут и тут).

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

В завершение статьи я хочу отметить, что после выбора сервис-провайдера и сайзинга заказчик оказывается перед более трудной задачей — миграцией своих сервисов в облако. Например, с командой #CloudMTS можно обсудить:

А если вы планируете переносить 1С в облако, советую обратить внимание на наш специализированный хостинг. Вы можете выбрать подходящий по стоимости сегмент ресурсов, а специалисты #CloudMTS подберут оптимальную конфигурацию, настроят инфраструктуру и при необходимости помогут перенести данные. А для тех, кто работает с персональными данными, есть защищенный сегмент 152-ФЗ.

Источник