По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие наши статьи:
img
Сегодня хотим поговорить про модуль «Web Callback» для FreePBX 13. Модуль является платным и стоит $50. Платеж единоразовый. В сравнении с популярными сервисами обратного звонка, покупка модуля окупается в среднем за полгода. Интересно? Тогда читайте ниже: настройка и адаптация стиля под свой сайт. Процесс настройки Данный модуль находится в меню Applications. Он позволяет легко и просто добавить HTML “Позвоните Мне” код на ваш веб-сайт. Посетители просто вводят свой телефонный номер для соединения с нужной вам очередью или ринг-группой. Далее, этот модуль позволяет выставить префикс для поступающего номера, что позволит определить, что вызов идет именно с модуля обратного звонка. Так же можно указать правила набора номера, для определения номеров, на которые можно совершить вызов. Как только вы установите направление для вызова и подтвердите настройки модуля, вы получите HTML-код для добавления на вашу страницу. Итак, пошаговый процесс создания кода для помещения на веб-страницу: Нажмите на + Add Web Callback Заполните поля: Описание полей: Name – Название коллбэка CID Prepend – Префикс при определении номера, в данном случае – «CALLBACK» Number Prepend – Префикс при наборе номера Dial Matches – Маска, для определения номеров, которые можно набирать Icon – Выбор иконки из предложенных Valid Message – Сообщение, которое высвечивается при правильном наборе Invalid Message – Сообщение, которое высвечивается при неправильном наборе Error Message – Сообщение, которое высвечивается, если произошла какая-либо ошибка Destination – Направление вызова, в данном случае – ринг-группа с названием “web callback” HTML Code – Код, который появится после сохранения настроек Нажмите Submit Далее нужно только добавить получившийся код на сайт и пользоваться. Только надо учитывать два момента: первый – данный модуль надо купить у Shmooze и иметь публичный адрес вашей АТС/или пробрасывать порты. Изменения стиля формы обратного звонка После того как мы создали форму обратного звонка на сайт, нам необходимо доработать ее внешне, так как встроенные формы имеют не привлекательный дизайн. Открываем файл /etc/schmooze/wcb.html и добавляем в него следующий код: <style type="text/css"> #frame { background-image: url('/admin/images/webcallback.png'); background-repeat: no-repeat; background-size: 200px; height: 65px; cursor: pointer; cursor: hand; } #webcallbackinput { position: relative; left: 66px; top: 30px; width: 125px; } </style> <div id="frame"> <input type="text" name="num" placeholder="Укажите ваш номер" id="webcallbackinput" value=""> <input type="hidden" id="dest" value="http://1.2.3.4:12345/wcb.php"> <input type="hidden" id="i" value="1"> </div> <div id="link"></div> <script type="text/javascript" src="https://ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script> <script type="text/javascript"> $(document).ready(function(){ $('#frame').click(function(){ if ($('#webcallbackinput').val()) { var valid_msg = 'Спасибо. Мы уже звоним Вам!'; var invalid_msg = 'Ошибка. Пожалуйста, укажите все параметры согласно требованию полей'; var but = $(this); $.ajax({ url: $('#dest').val(), type: 'post', data: {p: $('#webcallbackinput').val(), i: $('#i').val()}, cache: false, success: function(data, b, c) { data = $.parseJSON(data); switch (data.Response) { case 'Error': switch (data.Message) { case 'Originate failed': alert(invalid_msg); break; default: alert(data.Message); break; } break; case 'Success': alert(valid_msg); break; default: break; } }, error: function(a, b, c) { alert(invalid_msg); } }) } }) }); </script> Обратите внимание, чтобы форма работала корректно, вам необходимо указать корректное значение параметра value в поле input ниже (это значение было сгенерировано на этапе настройки в поле) и значение параметр id в поле, следующем следом за ним. В нашем примере, id=2: <input type="hidden" id="dest" value="http://1.2.3.4:12345/wcb.php"> <input type="hidden" id="i" value="1"> В данном примере указано значение http://1.2.3.4:12345/wcb.php , где значение 1.2.3.4 – внешний IP – адрес нашего маршрутизатора, а 12345 – это проброс нестандартного порта в наш Asterisk. Рекомендуем в настройках проброшенного порта указать разрешенные сети (source address), с которых можно подключиться через этот порт. Это необходимо в целях безопасности, если ваш Web – сервер находится не в локальной сети, а например, на хостинге Так же здесь вы можете настроить сообщения, которые будут показаны пользователю при успешном и неуспешном исходе вызова обратного звонка var valid_msg = 'Спасибо. Мы уже звоним Вам!'; var invalid_msg = 'Ошибка. Пожалуйста, укажите все параметры согласно требованию полей ';
img
REST API – один из самых распространенных типов доступных веб-сервисов, но проектировать их сложно. Они позволяют разным клиентам, включая браузер, настольные приложения, мобильные приложения и практически любое устройство с подключением к Интернету, взаимодействовать с сервером. Именно поэтому очень важно правильно проектировать REST API, чтобы в будущем не было проблем. Создание API с нуля может оказать непосильной задачей из-за большого количества вещей, которые необходимо учесть – от базовой безопасности до использования правильных методов HTTP, реализации аутентификации, определения того, какие запросы и ответы среди многих других принимаются и возвращаются. В этой статье я очень постарался сжать материал в 15 пунктов с важными рекомендациями, которые позволят создать хороший API. Все рекомендации никак не зависят от языка, поэтому потенциально применимы к любой платформе или технологии. 1. Обязательно используйте имена существительные в названиях путях к конечным точкам Вам всегда следует использовать имена существительные, которые обозначают объект, который вы извлекаете или которым вы манипулируете. В качестве имени пути всегда предпочтительнее использовать множественное число. Избегайте использования глаголов в названиях путях к конечным точкам, потому что наш метод HTTP-запроса уже является глаголом и по сути не добавляет никакой новой информации. Действие должно быть произведено с помощью методов HTTP-запроса. Наиболее распространенными являются методы GET, POST, PATCH, PUT и DELETE. GET извлекает ресурсы POST отправляет новые данные на сервер PUT/PATCH модифицируют уже существующие данные DELETE удаляет данные Глаголы сопоставляются с функциями CRUD (Create, read, update и delete). Помня об этих принципах, мы должны создавать маршруты типа GET /books для получения списка книг, а не GET /get-books или GET /book. Аналогично, POST /books - для добавления новой книги, PUT /books/:id - для модификации полных данных книги с заданным идентификатором (id), а PATCH /books/:id обновляет частичные изменения в книге. И наконец, DELETE /books/:id предназначен для удаления существующей книги в заданным идентификатором. 2. JSON как основной формат отправки и получения данных Несколько лет назад прием и ответы на запросы API выполнялись в основном в XML. Но сейчас «стандартным» форматом для отправки и получения данных API в большинстве приложений стал JSON. Поэтому наш второй пункт рекомендует убедиться, что конечные точки возвращают формат данных JSON в качестве ответа, а также при приеме информации через полезную нагрузку HTTP-сообщений. Несмотря на то, что FormData хорошо подходит для отправки данных от клиента, особенно если нам нужно отправлять файлы, они не очень подходят для текста и чисел. Нам не нужны FormData для их передачи, так как в большинстве фреймворков можно передавать JSON непосредственно на стороне клиента. При получении данных от клиента нам необходимо убедиться, что клиент правильно интерпретирует данные JSON, и для этого при выполнении запроса в заголовке ответа Content-Type должен быть установлен на application/json. Стоит еще раз упомянуть исключение, когда мы пытаемся отправлять и получать файлы между клиентом и сервером. В этом конкретном случае нам необходимо обрабатывать файл ответа и отправлять FormData с клиента на сервер. 3. Используйте коды состояний HTTP Коды состояний HTTP всегда полезно использовать для того, чтобы указать на выполнение или невыполнение запроса. Не используйте слишком много кодов состояний и всегда используйте одни и те же коды для одних и тех же результатов в API. Вот некоторые примеры: 200 – общее выполнение 201 – успешное создание 400 – неверные запросы от клиента, такие как неверные параметры 401 – несанкционированные запросы 403 – отсутствие прав доступа к ресурсам 404 – отсутствуют ресурсы 429 – слишком много запросов 5хх – внутренние ошибки (их следует избегать насколько это возможно) В зависимости от ситуаций их может быть и больше, но ограничение количества кодов состояний помогает клиенту использовать более предсказуемый API. 4. Возвращайте стандартизированные сообщения Помимо использования кодов состояния HTTP, которые указывают на результат запроса, всегда используйте стандартизированные ответы для аналогичных конечных точек. Пользователи могут всегда рассчитывать на одинаковую структуру и действовать соответственно. Это также относится к статусу, указывающему на выполнение запроса, и сообщениях об ошибках. В случае выборки коллекций придерживайтесь определенного формата, независимо от того, включает ли тело ответа массив данных, подобный этому: [ { bookId: 1, name: "The Republic" }, { bookId: 2, name: "Animal Farm" } ] или вот такой комбинированный ответ: { "data": [ { "bookId": 1, "name": "The Republic" }, { "bookId": 2, "name": "Animal Farm" } ], "totalDocs": 200, "nextPageId": 3 } Здесь рекомендация заключается в том, чтобы быть последовательным независимо от того, какой подход вы выберете для этого. Аналогичное поведение должно быть реализовано при извлечении объекта, а также при создании и модификации ресурсов, которым обычно рекомендуется возвращать последний экземпляр объекта. // Ответ после успешного вызова POST /books { "bookId": 3, "name": "Brave New World" } Хоть это и никак не навредит, но все же излишнем будет включать универсальное сообщение, например, «Книга успешно создана», так как это уже следует из кода состояния HTTP. И последнее, но не менее важное: при наличии стандартного формата ответа коды ошибок также важны (и даже более важные). Это сообщение должно включать информацию, которую клиент может использовать для представления ошибок конечному пользователю, а соответственно, это должно быть не общее предупреждение, такое как «то-то пошло не так», которого следует избегать, насколько это возможно. Вот пример: { "code": "book/not_found", "message": "A book with the ID 6 could not be found" } Опять же, нет необходимости включать код состояния в содержимое ответа, но полезно определить набор кодов ошибок, таких как book/not_found, чтобы пользователь мог сопоставить их с разными строками и создать свое собственное сообщение об ошибке для конечного пользователя. В частности, для сред разработки или промежуточных сред может показаться правильным также включить стек ошибок в ответ с целью помочь в отладке ошибок. Но не включайте те, что находятся в промышленной эксплуатации, так как это создаст угрозу безопасности, раскрывая незапланированную информацию. 5. Используйте разбиение на страницы, фильтрацию и сортировку при выборе коллекций записей Как только будет создана конечная точка, которая возвращает список элементов, необходимо будет установить разбиение на страницы. Обычно коллекции со временем растут, поэтому важно всегда следить за тем, чтобы возвращалось ограниченное и контролируемое количество элементов. Справедливо будет позволить пользователям API выбирать, сколько объектов получить, но всегда полезно заранее определить число и установить для него максимум. Основная причина, почему нужно это сделать, заключается в том, что для возврата огромного массива данных потребуется очень много времени и большая пропускная способность. Для реализации нумерации страниц есть два хорошо известных способа: skip/limit или keyset. Первый вариант обеспечивает более удобный для пользователя способ извлечения данных, но обычно он менее эффективен, так как базы данных сканируют множество документов для извлечения нужных записей. Мне больше нравится второй вариант. Разделения на страницы с помощью keyset получает идентификатор (id) в качестве ссылки для «вырезания» коллекции или таблицы с условием без сканирования записей. Также API должны предоставлять фильтры и возможности сортировки, которые упрощают способы получения данных. Частью решения повышения производительности являются индексные базы данных, которые позволяют максимизировать производительность при помощи шаблонов доступа, которые применяются с фильтрами и параметрами сортировки. При проектировании API эти свойства разбиения на страницы, фильтрации и сортировки определяются как параметры запроса в URL-адресе. Например, если вы хотим получить информацию о первых 10 книгах, принадлежащих к категории «роман», то наша конечная точка будет выглядеть вот так: GET /books?limit=10&category=romance 6. PATCH вместо PUT Маловероятно, что необходимо будет сразу полностью обновить всю запись, обычно есть конфиденциальные или полные записи, которые следует уберечь от манипуляций пользователя. Именно поэтому для выполнения частичных обновлений ресурса следует использовать PATCH, а вот PUT полностью меняет существующий ресурс. Они оба должны использовать тело запроса для передачи информации, подлежащей модификации. Разница лишь в том, что для PATCH это поля, а для запроса PUT – полный объект. Тем не менее, стоит отметить, что ничто не мешает нам использовать PUT для частичной модификации, нет никаких «ограничений на передачу по сети», которые бы это подтверждали. Это просто факт, которого стоит придерживаться. 7. Предоставьте более подробные ответы Шаблоны доступа являются ключевыми при создании доступных ресурсов API и возвращаемых данных. Когда система растет, то и свойства записи также растут, но не всегда все эти свойства нужны клиентам для работы. Именно в таких ситуациях становится полезным предоставление возможности возвращать сокращенные или полные ответы для одной и той же конечной точки. Если пользователю нужны только некоторые поля, то упрощенный ответ помогает снизить расход трафика и потенциально сложность получения других вычисляемых полей. Простой способ реализовать – предоставить дополнительный параметр запроса, чтобы включить или отключить предоставление более подробного ответа. GET /books/:id { "bookId": 1, "name": "The Republic" }GET /books/:id?extended=true { "bookId": 1, "name": "The Republic" "tags": ["philosophy", "history", "Greece"], "author": { "id": 1, "name": "Plato" } } 8. Обязанность конечной точки Принцип единственной обязанности фокусируется на концепции удержания функции, метода или класса на одной обязанности, которую они выполняют хорошо. Мы можем сказать, что это наш API - хороший API, если он выполняет одну конкретную вещь и никогда не меняется. Это помогает пользователям лучше понять наш API и сделать его более предсказуемым, что облегчит общую интеграцию. Лучше всего расширить список доступных конечных точек, а не создавать очень сложные конечные точки, которые пытаются решить множество задач одновременно. 9. Предоставьте полную документацию по API Пользователи вашего API должны понимать, как использовать доступные конечные точки и чего ожидать. Это возможно только при наличии хорошей и подробной документации. Обратите внимание на следующие аспекты, чтобы ваша документация была полной. Доступные конечные точки с описанием их назначения Права доступа, необходимые для выполнения конечной точки Примеры вызовов и ответов Сообщения о предполагаемых ошибках Немаловажным является постоянное обновление документации после внесения изменений и дополнений в систему. Лучший способ для этого – сделать документацию по API неотъемлемой частью разработки. Двумя хорошо известными инструментами в данном вопросе являются Swagger и Postman – они доступны для большинства сред разработки API. 10. Используйте SSL для обеспечения безопасности и настройте CORS Безопасность – еще одно очень важной свойство, которым должен обладать наш API. Настройка SSL путем установки действительного сертификата на сервер обеспечит безопасную связь с пользователями и предотвратит некоторые виды потенциальных атак. CORS (Cross-origin resource sharing – Обмен ресурсами с запросом происхождения) – это функция безопасности браузера, которая ограничивает HTTP-запросы из различных источников, которые инициируются сценариями, запущенными в браузере. Если ресурсы вашего REST API получают непростые HTTP-запросы из разных источников, то вам нужно включить поддержку CORS для того, чтобы пользователи работали соответствующим образом. Протокол CORS требует, чтобы браузер отправил предварительный запрос на сервер и дождался утверждения (или запрос учетных данных) с сервера перед отправкой фактического запроса. Запрос предварительной проверки отображается в API как HTTP-запрос, использующий метод OPTIONS (среди других заголовков). Значит, для поддержки CORS в ресурсе REST API необходимо реализовать метод OPTIONS, который будет отвечать на предварительный запрос, по крайней мере, со следующими заголовками ответа, предусмотренными стандартом Fetch: Access-Control-Allow-Methods Access-Control-Allow-Headers Access-Control-Allow-Origin Какие значения назначать этим ключам, зависит от того, настолько открытым и гибким должен быть наш API. Мы можем назначить определённые методы и известные источники или использовать специальные символы, чтобы иметь открытые ограничения CORS. 11. Управление версиями API В процессе разработки конечные точки начинают меняться и перестраиваться. Но мы должны, насколько это возможно, избегать внезапного изменения конечных точек для пользователя. Рекомендуется рассматривать API как ресурс с обратной совместимость, в котором новые и обновленные конечные точки должны быть доступны, но не должны влиять на предыдущие стандарты. Вот где управление версиями API приходит на помощь – когда клиенты должны иметь возможность выбирать, к какой версии подключаться. Есть несколько способов описать управление версиями API: Добавление нового заголовка x-version=v2 Наличие параметра запроса ?apiVersion=2 Версия как часть URL: /v2/books/:id 12. Кэшируйте данные для повышения производительности Чтобы повысить производительность нашего API, полезно следить за данными, которые редко меняются и к которым часто обращаются. Для таких данных мы можем рассмотреть возможность использования базы данных в памяти или кэш-памяти, которая избавит от доступа к основной базе данных. Главная проблема здесь заключается в том, что данные могут устареть, поэтому следует решить вопрос с внедрением последней версии. Использование кэшированных данных будет полезным для пользователей для загрузки конфигураций и каталогов информации, которые не предназначены для постоянного изменения в течение долгого времени. При использовании кэширования не забудьте включить Cache-Control в заголовки. Это поможет пользователям эффективно использовать систему кэширования. 13. Используйте даты в формате UTC Сложно представить системы, которые в какой-то момент перестает работать из-за дат. На уровне данных важно быть логичным в том, как даты отображаются на клиентских приложениях. ISO 8601 – это международный стандартный формат данных для даты и времени. Данные должны быть в формате Z или UTC, для которых пользователи могут могли бы выбрать часовой пояс в случае, если такая дата должны отображаться при любых условиях. Вот пример того, как должны выглядеть даты: { "createdAt": "2022-03-08T19:15:08Z" } 14. Конечная точка проверки работоспособности Может произойти ситуация, когда наш API перестанет работать, и для его запуска потребуется время. При таких обстоятельствах клиенты хотят знать, что службы недоступны, и быть в курсе ситуации. Для этого предоставьте конечную точку (например, GET /health), которая бы определяла работоспособность API. Эта конечная точка может вызываться и другими приложениями, такими как балансировщики нагрузки. Можно продвинуться еще дальне и сообщать о периодах технического обслуживания или работоспособности частей API. 15. Разрешите аутентификацию по ключу API Аутентификация с помощью ключей API даст возможность сторонним приложениям легко создавать интеграцию с нашим API. Эти ключи API следует передавать с помощью пользовательского заголовка HTTP (например, Api-Key или X-Api-Key). Ключи должны иметь дату окончания срока действия, и должна быть возможность их отозвать с целью признания недействительными по соображениям безопасности.
img
NFV - виртуализация сетевых функций, это замена привычного оборудования (маршрутизаторов, коммутаторов и пр.) виртуальными аналогами, что даёт следующие возможности: Более эффективное использование ресурсов; Возможность использовать обычные высокопроизводительные сервера для любой задачи; Гибкое перераспределение ресурсов. Network Functions Virtualization Сети операторов связи состоят из большого многообразия различного физического оборудования. Для запуска новой службы или услуги часто необходима установка нового оборудования, что влечет за собой необходимость поиска свободного места в стойке, отдельного источника питания, специалиста обладающего необходимыми компетенциями и т.д. Более того, любое физическое оборудование в конце концов выходит из строя и перестает поддерживаться производителем, что провоцирует новый цикл интеграции оборудования на замену. Однако, в настоящее время темпы развития технологий крайне высоки и жизненный цикл оборудования еще более сокращается. Виртуализация сетевых функций нацелена на трансформацию принципа построения сетей за счет эволюции стандартов в технологиях виртуализации. Это поможет консолидировать сетевое оборудование в виде виртуальных машин на высокопроизводительных серверах, открытых коммутаторах и системах хранения, которые будут находиться в ЦОДах. Как было упомянуто, наибольшего прироста можно достичь с помощью одновременного использования SDN и NFV. На рисунке показано отношение между NFV, SDN и открытыми разработками в виде пересекающихся множеств. Виртуализации сетевых функций NFV Как видно из рисунка, виртуализация сетевых функций имеет общие черты с SDN технологией, однако не зависит от SDN, и наоборот. То есть NFV можно использовать без SDN, однако, при использовании сразу двух технологий можно, в перспективе, достичь хороших результатов. Кроме того, концепция SDN так же подразумевает использование мощных стандартизированных серверов и коммутаторов. Примеры использования виртуализации сетевых функций в корпоративных сетях и сетях операторов связи: Маршрутизаторы, шлюзы; HLR/HSS, SGN, SGSN, RNC, Node B, eNode B; Криптошлюзы; Офисные АТС; Сетевые экраны и системы предотвращения нежелательного доступа; DPI и анализаторы QoS; Мониторинговые и биллинговые службы; Сервера IMS - платформы; Сервера авторизации, балансировщики нагрузки. Преимущества виртуализации сетевых функций Как было упомянуто, использование данной концепции предоставляет много преимуществ, таких как: Уменьшенные капитальные расходы и токопотребление, увеличенные коэффициенты использования серверов; Уменьшение цикла инноваций и более быстрая разработка и предоставление инноваций; Возможность проводить тестирование, отладку на том же оборудовании, на котором запущены основные системы, что позволит сократить операционные расходы; При наличии распределенных ЦОДов возможность быстрой ре-локации виртуального оборудования без перерыва в работе для уменьшения задержки; Использование открытых разработок, большое количество документации, независимость от производителей оборудования; Оптимизация сетевой конфигурации иили топологии в зависимости от нагрузки в реальном времени; Возможность использования оркестраторов для полной автоматизации и независимости от человеческого фактора; Отказ от дорогого закрытого оборудования; Возможность временной реконфигурации в случае возникновения аварии, таким образом можно отказаться от операторов, следящих за состоянием сети и ЦОДа 24 часа в сутки; Возможность обновления без перерывов в работе, с легким возвратом версии в случае возникновении неполадок, возможность дупликации оборудования и синхронизации его состояния. Факторы, ускоряющие развитие виртуализации сетевых функций В первую очередь, таким фактором является быстрое развитие облачных технологий и появление большого количества ЦОДов. Виртуализация уже является ядром облачных технологий, и набирает ход использование таких открытых протоколов как OpenFlow - протокол для управления SDN - контроллером коммутаторами, OpenStack - оркестратор ЦОДа. Ранее, серьезным ограничителем являлось то, что серверные процессоры не были оптимизированы для обработки пакетов или потоков, но в настоящее время появились процессоры Intel Xeon, которые могут соперничать по производительности с граничными маршрутизаторами. Использование стандартизированных серверов на архитектуре x86 или x64, производство которых выросло за последние несколько лет позволит утилизировать преимущества NFV максимально. Факторы, сдерживающие развитие SDN и NFV Существует несколько известных проблем, сдерживающих быстрый рост ПКС и ВСФ: Проблема транспортировки виртуальных машин между ЦОДами, принадлежащих различных компаниям. Необходимо создание стандартизированного интерфейса, который позволил бы перемещать виртуальные машины с любого оборудования с использованием любого ПО для виртуализации. В настоящее время по причине большого количества вендоров ПО и оборудования — это практически невозможно; Проблема быстрого и однозначного выигрыша в производительности, так как необходимо использовать стандартные высокопроизводительные сервера, не получится использовать наработки различных вендоров, которые программно и аппаратно ускоряли обработку пакетов, потоков и т.д. Главный вопрос состоит в минимизации падения производительности по сравнению со старой схемой; Проблема миграции с физического оборудования на виртуализированное: для массового внедрения ВСФ необходимо проводить работы одновременно на всех крупных операторах связи для поддержания работоспособности и совместимости между оборудованием и системами управления сетью, OSS/BSS. Кроме того, необходимы инструменты для осуществления миграции с физического оборудования на виртуализированное; Стандартизация средств управления и автоматизации NFV. Использование и дальнейшее развитие ПКС позволит эффективно управлять виртуальными машинами и виртуализированным оборудованием с помощью контроллеров SDN; Вопрос масштабируемости будет закрыт только при условии полной автоматизации всех процессов виртуализации; Сетевая стабильность: необходима полная отказоустойчивость систем при управлении ЦОДом и автоматизации работы большого количества виртуальных машин от разных производителей оборудования. Особенно этот вопрос важен при обновлении и ре-локации систем. Вопрос безошибочного взаимодействия систем управления трафиком, балансировщиков нагрузки, контроллеров коллизий. Однако, данный вопрос до сих пор остается нерешенным в нынешних ЦОДах; Вопрос безопасности и отказоустойчивости: необходимо доказать, что использование SDN и NFV не ухудшит состояние систем информационной безопасности. Необходимо создание сертифицированных с точки зрения безопасности гипервизоров и виртуальных машин; Сложность управления: необходимо добиться серьезного уменьшения затрат на обслуживание и управление системами и избежать смены одной системы, на управление которой тратятся значительные ресурсы на другую; Проблемы интеграции: необходима легкая интеграция различного виртуального оборудования с различным физическим оборудованием при присутствии на рынке предложений от большого количества производителей. Обязательна легкая интеграция новейших разработок и стороннего ПО в системы управления и взаимодействия.
ВЕСЕННИЕ СКИДКИ
40%
50%
60%
До конца акции: 30 дней 24 : 59 : 59