Инстрим

 

Главная страница Обратная связь Карта сайта

Инстрим

Главная arrow Решения arrow Центры хранения и обработки данных arrow Сложности и принципы построения централизованных информационных систем

 
 
 

Сложности и принципы построения централизованных информационных систем

При построении ЦОД довольно часто приходится преодолевать последствия так называемой лоскутной автоматизации. До сих пор даже в самых передовых, с точки зрения применения информационных технологий, организациях процветают настоящие «зоопарки» из различных систем, созданных разными людьми. Характерный пример: компания в рамках создания ЦОД для построения ERP-системы выбрала самую свежую версию от одного из ведущих поставщиков ERP-систем. В итоге системному интегратору пришлось стыковать огромное количество других, разнообразных, но что самое ужасное – территориально-распределенных систем, и это в отсутствие на рынке стандартных инструментов, обеспечивающих безболезненную миграцию данных и приложений.

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

Первый, самый высокоуровневый подход к построению централизованных систем заключается в следующем: в качестве входных данных для проектируемой системы используются требования бизнеса заказчика. Подобный подход часто обозначают термином «виртуализация ИТ-сервисов». В этом случае заказчика, по большому счету, не интересует, на каких мощностях исполняются его задачи, какова емкость используемых систем хранения данных и что за каналы передачи данных задействованы. У заказчика есть только вход в систему, и он знает, какой результат должен быть получен в точно заданное время – а система для него своего рода «черный ящик».

Такие параметры, как результат, время его получения и гарантия того, что система будет работоспособной, являются единственным, что интересует клиента в этом случае. Эти параметры, как правило, обозначают термином SLA (service level agreement) – соглашение об уровне качества услуг. В итоге на верхнем уровне моделирования построение ЦОД предполагает формирование набора SLA, который и предоставляется заказчику. Как правило, процесс утверждения лежит на плечах ИТ-директора компании-заказчика – именно он предлагает руководству те сервисы, которые предприятие будет использовать в процессе решения тех или иных бизнес-задач. Иными словами: не вдаваясь в технические подробности, руководство предприятия знает, за какое время могут быть получены необходимые сведения или отчеты. Известно также, что время простоя системы в течение года гарантированно не будет превышать нескольких минут.

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

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

В зависимости от пожеланий, готовности заказчика и нужд его бизнеса выбирается тот или иной подход к построению ЦОД. Если клиента интересует исключительно удобство эксплуатации системы – можно начинать внедрение с третьего уровня. Если заказчик не может сформировать SLA, потому что бизнес пока не готов к столь тесному увязыванию с ИТ, можно начинать со второго уровня – построения архитектуры. И, наконец, компании со зрелым бизнесом начинают внедрение с самого верхнего уровня.

 
 

Все права защищены © «Инстрим КТ»