Amazon анонсировал обновление своего сервиса миграции баз данных (DMS). Улучшения касаются миграции данных из NoSQL-баз данных c открытым кодом MongoDB. Это позволит пользователям легко переносить свои данные во внутреннюю базу данных AWS DynamoDB.

До недавнего времени сервис миграции в AWS поддерживал только Oracle, MS SQL Server, MySQL, Aurora, PostgreSQL и SAP ASE. AWS
также заявляет, что теперь DMS поддерживает миграцию из баз данных NoSQL «в целом». Под словом «в целом» можно понимать, что
в ближайшем будущем будут объявлены и другие базы данных, поддержка которых будет осуществляться не «в целом», а явно.

DMS является важным звеном среди услуг AWS. По данным компании миграция баз данных с помощью DMS была осуществлена порядка 16 тыс. раз только в декабре прошлого года, а в марте этого года – уже 22 тыс. раз.

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

По материалам TechPortal

Приобретение компанией Microsoft стартапа Deis дает возможность Microsoft применить нужную ей функциональность для Kubernetes, которая очень легка в использовании и может быть использована с контейнерами Azure.

Microsoft уже поддерживает Kubernetes в Azure, теперь получит возможность использовать в Azure разработки Deis.

Продукт под названием Helm, пакетный менеджер для Kubernetes, автоматизирует сборку приложений на Kubernetes, и в какой-то мере похож на Docker Hub или Quay.

Другие два продукта: Workflow и Steward также облегчат управление приложениями в среде Kubernetes.

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

По материалам InfoWorld

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

Согласно опубликованному в прошлом месяце отчету, у Huawei отмечен самый медленный рост прибыли за последние 5 лет. Чтобы увеличить темпы,
компания намерена создать отдельное подразделение облачных услуг и нанять порядка 2000 специалистов. Расширяя облачные предложения, компания надеется увеличить выручку, приносимую
программными продуктами, в то время как выручка, приносимая «железом» – смартфонами и инфраструктурным оборудованием – замедляет свой рост.

Президент нового подразделения Чжень Елай заявил: «Мы ранее фокусировались на частных облаках и достигли хороших успехов, теперь наша цель – усилить предложения публичных облачных услуг».

Эрик Цзю, заместитель председателя совета директоров Huawei заметил, что компания не собирается отбирать долю рынка у конкурентов за счет демпинга.
В качестве преимуществ Huawei, которые помогут компании увеличить продажи облачных услуг, Цзю отметил существующие партнерства с операторами в Европе и
сильное присутствие компании в развивающихся странах.

По материалам Reuters

Следующая версия СУБД от Microsoft будет выполнять скрипты на Python, как хранимые процедуры T-SQL, при полном доступе к сторонним библиотекам для Python.

Начиная с версии CTP 2.0 SQL Server 2017 скрипты на Python могут быть использованы для аналитики, запуска моделей машинного обучения, да и вообще для любых других задач обработки данных.

Эта интеграция не ограничена корпоративными версиями SQL Server 2017, это будет доступно даже в бесплатной версии Express.

Наиболее типичное применение Python c SQL Server – это запускать скрипты Python как обычно, используя SQL Server как источник данных. Microsoft также дает возможность внедрять код на Python в базы данных, как хранимую процедуру T-SQL.

Наличие инсталляции Python не требуется. Во время процесса установки SQL Server 2017 может скачать и установить CPython 3.5, но пользователи могу устанавливать свои дистрибутивы Python.

Пользователям Linux, однако, придется пока подождать. Хотя Microsoft и обещала, что SQL Server будет работать на Linux также, как на Windows, пока только Windows-версия поддерживает Python.

По материалам InfoWorld

Если у вас есть сервер, работающий под управлением Windows Server 2003 – у вас проблема. Этот сервер может быть относительно легко взломан. Стандартное решение – обновить версию сервера – подходит далеко не всем.

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

Так что же делать тем, кто должен поддерживать машины под управлением Windows Server 2003?

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

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

• «Белые списки» приложений: можно также воспользоваться «белыми списками» приложений, которые можно запускать на сервере.

• Резервное копирование: это то, что «по умолчанию» необходимо делать всегда. В данном случае это еще более необходимо, поскольку становятся все более распространены вредоносные программы, которые шифруют данные на машине и вымогают деньги за восстановление доступа к ним.

По материалам IT World

Компания Amazon представила новый сервис CodeStar, а также расширила возможности сервиса DynamoDB.

DynamoDB обычно используется для игровых, мобильных и веб-приложений. Ранее, для обеспечения доступа к данным со скоростью, близкой к «в реальном времени», разработчикам приходилось разворачивать кластера кэширования in-memory для приложений DynamoDB.

Теперь Amazon предлагает DynamoDB Accelerator (DAX), полностью управляемый кэш in-memory, который снижает время ответа от базы данных с миллисекунд до микросекунд даже при объемах запросов в миллионы в секунду.

Разработчики могут подключить DAX к приложениям DynamoDB через консоль управления AWS, и это не потребует изменения кода приложений.

Новый сервис AWS CodeStar обеспечивает единый интерфейс управления политиками безопасности для групп разработчиков и позволяет автоматически конфигурировать проекты, которые используют сервисы CodeCommit, CodeBuild, CodePipeline and CodeDeploy.

CodeStar является попыткой AWS обеспечить более высокий уровень абстракции для разработчиков. AWS обеспечивает шаблоны для EC2, Elastic Beanstalk или Lambda,
а CodeStar может быть использован с JavaScript, Java, Python, Ruby и PHP. Сервис поддерживает Visual Studio, Eclipse или любую другую
интегрированную среду разработки с поддержкой Git, а также интегрируется с JIRA.

Нет, речь пойдет не о том, что AWS – какая-то «плохая» платформа, а скорее о том, что AWS может начать конкурировать со своими клиентами.

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

Похоже на то, что теперь Amazon собирается повторить этот трюк с AWS – облачной платформой, которой пользуются множество стартапов. Риск особенно велик для тех стартапов, чья функциональность может считаться дополняющей предложения AWS. Давайте рассмотрим конкретные примеры:

• В октябре 2015 года Amazon представила свой инструмент визуализации данных QuickSight, в то время как партнерская компания Tableau, обеспечивающая похожие услуги, анонсировала, что будет более плотно интегрироваться с AWS.

• Сервисы X-Ray и Pinpoint, анонсированные в декабре 2016 года, явно конкурируют с сервисом New Relic и другими сервисами мониторинга.

• В феврале 2017 года компания анонсировала Chime – платформу для видеоконференций и коммуникаций внутри команды. Этот продукт конкурирует с массой других сервисов, начиная со Skype for Business, WebEx, и до менее известных Blue Jeans, Zoom и других.

• В марте 2017 года Amazon представила Connect – ПО для колл-центров. Этот продукт впрямую конкурирует с популярным стартапом Talkdesk, работающим на AWS.

• Ну и наконец недавно Amazon представила сервис CodeStar, для облегченной разработки и разворачивания приложений. Этот сервис вполне может «убить» Heroku, когда его функциональность расширится.

Пока об этой тенденции еще не говорят со страниц Wall Street Journal, но в частных разговорах директора различных SaaS уже
опасаются, что скоро окажутся конкурентами своему собственному хостеру приложений. Учитывая гигантские возможности Amazon в плане маркетинга и финансов, никто бы
не хотел конкурировать с Amazon. Один из директоров прямо заявил журналисту Inc.com, что по его мнению Amazon делает с SaaS
то же самое, что и с началом продаж популярных товаров под маркой Amazon Basics: находит популярные ниши и создает в
них свой продукт.

Генеральному директору Amazon Джеффу Безосу приписывают следующую цитату: «Ваша прибыль – это моя возможность». И похоже, что это в точности описывает отношение компании к различным SaaS-платформам.

По материалам Inc.com

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

Вы, конечно, знаете, что использование Linux в дата-центре может помочь сэкономить на стоимости лицензий и обслуживании. Но какие из дистрибутивов больше всего подходят для работы в дата-центре? Специалисты ServerWatch выбрали 10 наиболее подходящих Linux-дистрибутивов для серверов.

Ubuntu превосходит остальные дистрибутивы Linux для серверов – начиная от простой инсталляции, до восстановления после проблем с оборудованием или классной поддержки.

Последний релиз 16.10 поддерживает OpenStack Newton, Kubernetes и апдейты в виде Juju 2.0 и MaaS 2.0 для технологии Canonical Metal-as-a-Service.

RED HAT ENTERPRISE LINUX

ОС Red Hat Enterprise Linux (RHEL) для серверов является одним из ключевых игроков на рынке дата-центров.

RHEL основана на Fedora. Дебют ОС состоялся в июне 2014 года, с тех пор прошло несколько апдейтов, после которых ОС получила возможности масштабирования, включая новую файловую систему, которая может поддерживать до 500 терабайт, а также поддержку контейнеров Docker.

SUSE LINUX ENTERPRISE SERVER

Это надежный дистрибутив, основан на openSUSE Linux с дополнительным фокусом на стабильности и поддержке.

Последний релиз вышел в октябре 2014 года и принес поддержку Docker, полное восстановление системы. Последний сервис-пак SLES 12 SP2 вышел в декабре 2016 года, в нем поддерживается Open vSwitch и стандарт криптопроцессоров Trusted Platform Module 2.0.

CENTOS

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

CentOS 7.2 вышла в декабре 2015 года и основана на RHEL 7.2.

Возможно, вы удивлены, что Debian попал сюда, но несмотря на отсутствие коммерческой поддержки, вы можете пользоваться услугами консультантов по Debian со всего мира, которые указаны на странице Consultants. Debian был «рожден» в 1993 году и дал больше дистрибутивов-«потомков», чем другие.

В Debian произошел переход от SysVinit к systemd, а сам дистрибутив включает последние релизы Linux Kernel, Apache, LibreOffice, Perl, Python, Xen Hypervisor, GNU Compiler Collection, GNOME и Xfce. Debian 8.6 вышел в сентябре 2016 года.

ORACLE LINUX

Если вы не знали, что Oracle имеет свой собственный Linux, вы – не одиноки. Это клон RHEL, с некоторым «добавками» от Oracle.

Оптимизированный для баз данных Oracle, Oracle Linux является значимым игроком на рынке серверного Linux. Последний релиз, 7.3, вышел в ноябре 2016 года и основан на RHEL 7.3.

MAGEIA / MANDRIVA

Mageia – это появившийся в 2011 году форк с открытым кодом от Mandriva Linux. Mandriva широко популярна в Европе и в Южной Америке.

Mageia 5 доступна с июня 2015 г., а Mageia 6 ожидается в начале 2017 г.

CLEAROS

ClearOS основана на RHELи CentOS.  Удобный админский интерфейс и подробная документация делает ClearOS неплохим выбором для не очень опытных администраторов, либо пользователей, кому надо быстро поднять сервер на Linux без лишних «заморочек».

ClearOS доступна бесплатно, и в то же время предлагает недорогую профессиональную версию с опциями поддержки и дополнительными функциями.

Последний релиз, 7.2, получил улучшенную поддержку виртуальных машин, включая Hyper-V, XFS, BTRFS, IPv6 и кэширования LVM.

ARCH LINUX

Простой и «легкий» дистрибутив, который создан для более опытных пользователей. В Arch Linux нет поддержки или легкости использования других версий, но он вполне может использоваться опытными админами.

Как и в Gentoo Linux, Arch Linux использует модель «rolling release», что означает, что регулярное обновление системы – это все, что требуется, чтобы получать последние компоненты и пакеты.

SLACKWARE

Хотя Slackware редко ассоциируется с коммерческими продуктами, несколько компаний предоставляют платную поддержку для этой платформы.

Это один из самых ранних дистрибутивов для серверов, впервые выпущенный в 1993 году, поэтому у Slackware существует мощная база поклонников. Разработчики регулярно выпускают новые версии, последний релиз, 14.2, вышел в июле 2016 г.

По материалам ServerWatch

VIRTUAL SECURE MODE (VSM)

Рассмотрим основные моменты

• Защита от киберпреступлений
• Защита от ответственности

• возмещения убытков (в этом случае правообладатель должен предоставить расчет причиненных убытков; как правило, суды полностью удовлетворяют требования пострадавших правообладателей), либо
• выплаты компенсации, определяемой по усмотрению суда, в размере от 10 000 до 5 000 000 рублей либо в двукратном размере стоимости
  экземпляров произведения или в двукратном размере стоимости права использования произведения, определяемой исходя из цены, которая при сравнимых обстоятельствах обычно взимается
  за правомерное использование произведения. Компенсация выплачивается независимо от наличия или отсутствия убытков.

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

1. Придется существенно поднять расценки, ведь рано или поздно компенсацию придется платить.
2. Возникает значительный риск полного разорения оператора ДЦ. Для этого достаточно пары аварий подряд. И клиенту придется срочно переезжать  из закрывающегося ДЦ.
3. Если случилась авария, то нужно найти ее причины и принять меры, чтобы не допустить повторения. Но меры, как правило, требуют расходов, а бюджет оператора получит сильнейший удар после выплаты большой компенсации. В результате ему придется экономить на техническом обслуживании.

• Сотрудники, имеющие уголовное прошлое, работают лучше тех, кто был «чист» перед законом
• Повторно нанятые сотрудники покидают компанию на 44% быстрее, чем те, кто пришел в компанию впервые

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

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

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

ПАРКОВКИ

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

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

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

ГОРНЫЕ ЛЫЖИ

В 2003 году исследование журнала SKI Magazine показало, что недополученная выручка горнолыжных курортов может составлять до 8% из-за фрода.

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

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

Но наиболее удивительным примером является производство горных лыж. Производственный цикл сократился до двух недель. Technica Group, куда входят такие бренды
как Blizzard и Nordica, использует IBMC ognos, чтобы вносить изменения в свои производственные процессы. По их данным, им удалось на
48% улучшить предсказание спроса с помощью big data, и на 30% снизить простои производственных линий.

НАРУЖНАЯ РЕКЛАМА

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

Были собраны данные по 1600 населенным пунктам, а общее количество записей в базе данных составило 160 миллионов.

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

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

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

По материалам Datamation.

Рискованно ли полагаться только на трафик из поисковых систем?

Какой процент органического трафика должен идти от поисковиков?

6 способов, как эксперты рекомендуют диверсифицировать органический трафик

Рассмотрим 10 топовых баз данных по версии ServerWatch.

• VMware vRealize Operations 6.1- для обеспечения консистентной структуры управления при переходе от частного к гибридному облаку. С новой функцией Intelligent Workload
  Placement продукт соотносит нагрузку и потребности клиента, и рекомендует наилучшее размещение. Функция Proactive Rebalancing позволяет проводить ребалансировку и постоянно обеспечивать
  соответствие потребностям. Мониторинг за операционной системой и приложениями будет нативно доступен, и предиктивная аналитика позволит службам ИТ заранее определять потенциальные
  проблемы по всей инфраструктуре и стекам приложений.
• vRealize Log Insight 3 – удвоит производительность до 15 000 сообщений в секунду. Продукт также получит улучшенную толерантность к проблемам с кластерами, улучшенную интеграцию с vRealize Operations, и более быстрое исполнение запросов.
• VMware Integrated OpenStack 2 – продукт основан на OpenStack Kilo, будет доступен через программу VMware vCloud Air Network
• VMware Site Recovery Manager 6.1 – будет интегрирован с NSX 6.2. Позволит командам ИТ использовать виртуализацию сети, чтобы упростить восстановление
  после аварии и ускорить восстановление в случает программно-определяемых дата-центров. Этот продукт организует миграцию виртуальных машин между сайтами, автоматизируя операции vMotion.
  Продукт также будет работать совместно с vSphere Storage Policy-Based Management, чтобы обеспечить при аварии автоматическую защиту виртуальных машин, основанную на
  созданных политиках. Продукт также поддержит кластерные решения, такие как EMC VPLEX, Hitachi Virtual Storage Platform, и IBM San Volume Controller.


• VMware vSphere APIs for IO Filtering – продукт позволит вендорам-партнерам, таким как Asigra, EMC, Infinio, PrimaryIO, Samsung, SanDisk и StorageCraft
  предоставлять программно-определяемые сервисы, такие как репликация и кэширование. Эти сервисы данных будут полностью интегрированы в vSphere и управляться через vSphere
  Storage Policy-Based Management.
• VMware NSX 6.2– продукт позволит организациям обеспечить постоянство приложений через восстановление после аварий. VMware утверждает, что с NSX клиенты могут добиться уменьшения времени восстановления на 80%. NSX 6.2 также улучшает интеграцию с физической инфраструктурой.

• Docker Engine for Windows Server
• Docker Command Line Tools
• Visual Studio 2015 Tools for Docker

• Умное управление нагрузкой: система обеспечивает, оптимизирует и постоянно управляет облачной инфраструктурой состоящей из разных технологий (Hadoop, MPP SQL, Spark и так далее), чтобы обеспечить необходимые SLA
• Автоматизация «с-начала-до-конца»: переносит данные и запускает аналитические процессы в облаке, с коннекторами к средствам предприятия и источникам данных
• Безопасность: интегрирует шифрованное облако данных с предприятием, используя сильные механизмы шифрования, управления и контроля за соблюдением процедур.

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

Но в некоторых случаях, «дешево» — это именно то, что вам нужно, а насчет надежности можно и потерпеть. И это, похоже, та самая идея в основе нового облачного сервиса от Google по аренде виртуальных машин, называемого Google Compute Engine Preemptible.

И уж что касается слова «дешево», то это соответствует сервису в полной мере — цена на виртуальные машины в Preemptible доходит до 0,5 цента за ядро в час, и часто в половину меньше стандартных цен.

Но про надежность тут можно забыть. Основная «фича» этого сервиса в том, что любая виртуальная машина может быть выключена в любое время без какого-либо предупреждения. Бах! И ее нет.

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

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

Ну и конечно, никто ведь не заставляет использовать вычислительные мощности только такого сервиса. Например, вполне можно запустить кластер Hadoop в облаке Google и настроить его так, чтобы скажем 25% серверов в кластере были виртуальными машинами Preemptible.

Что может случиться самого плохого в таком сценарии? Если все 25% машин пропадут, то ваши процессы Big Data начнут занимать несколько дольше,
чем вы привыкли. Но положительный момент в том, что это будет стоить вам лишь чуть-чуть больше при том, что с большой вероятностью все ваши
задачи станут исполняться гораздо быстрее.

В частности, команда безопасности Google Chrome запускала свое средство под названием Clusterfuzz, чтобы выполнять рандомизированные проверки безопасности. Обладая большой вычислительной мощностью,
команда может находить ошибки в коде безопасности быстрее. С помощью виртуальных машин Preemptible они смогли удвоить мощности, в то же время снизив затраты, — заявляет
Нэш.

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

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

По материалам ServerWatch.com

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

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

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

Идея bare metal состоит в использовании выделенных серверов для создания облаков. Этому словосочетанию еще не придумали адекватного перевода на русский язык, в некоторых источниках встречается «голое железо» или «чистое железо».

В среде bare metal виртуальные машины инсталлируются прямо на железо, а не в хост операционной системы.

Облако на «голом железе» обеспечивает возможность заменить виртуальную облачную среду средой с выделенными серверами, что дает возможность «сэкономить» ресурсы на
виртуализации, не жертвуя при этом гибкостью, масштабируемостью и эффективностью. Сервера bare metal не содержат гипервизор, и не виртуализированы, но могут
быть предоставлены в пользование клиенту через подобную облаку модель услуг.

«Учитывая ту скорость, которая нужна для обработки аналитических запросов, вы вполне можете найти разумным удалить нагрузку на процессор от программного
слоя извлечения», - говорит Эндрю Смит, аналитик из Technology Business Research. «Поэтому использование bare metal для быстрого аналитического движка может
быть вполне удачным кейсов использования».

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

По материалам ComputerWeekly и TechTarge

• Постоянное шифрование – новая возможность, призванная защитить данные во время хранения и при передаче
• Улучшения технологий обработки данных в памяти «Хекатон» для получения аналитики в реальном времени
• Новая аналитика баз данных с интеграцией с решением R компании Revolution
• Polybase – движок, который до этого был частью SQL Server Parallel Data Warehouse Appliance, предназначенный для более легкого управления реляционными и не-реляционными базами данных
• Безопасность на уровне строк, позволяющая контролировать доступ к данным в зависимости от характеристик пользователя
• Динамическая маскировка данных – поддерживает нарушение данных в реальном времени, чтобы предотвратить неавторизованный доступ
• Поддержка времени в базах данных – отслеживание изменений в базе данных с течением времени
• Хранилище запросов к данным – «черный ящик» для администраторов баз данных
• Улучшенный гибридный бэкап в Azure и более быстрое восстановление в SQL Server в виртуальных машинах Azure.

Microsoft выпустила Windows Nano Server – глубоко переработанную версию операционной системы, требующую гораздо меньше ресурсов системы.

Windows Nano Server создан как можно более «легким» решением. По словам представителей Microsoft: «Nano Server это сильно облегченная версия Windows
Server с удаленной установкой и оптимизированная для облака и рабочего процесса DevOps. Она создана для меньшего количества разных патчей и
апдейтов, более быстрого рестарта, лучшего использования ресурсов и усиленной безопасности».

Результат: система, которая по заявлению Microsoft, требует на 93% меньше места на жестком диске, на 92% меньше проблем с безопасностью и на 80% меньше необходимости перегружать систему.

Естественно, такие выгоды обошлись за счет чего-то. «Чтобы добиться такого результата, мы убрали стэк GUI, 32-битную поддержку, MSI и некоторых
стандартных компонент Server Core» - рассказывает команда проекта. «В системе нет локального логона или поддержки Remote Desktop. Все управление осуществляется
удаленно через WMI и PowerShell. Мы также добавили Windows Server Roles and Features через Features on Demand и DISM.» Несмотря
на это Nano Server остается API-совместимым с другими вариантами Windows Server, что позволяет предположить, что переносить приложения между платформами будет
легко.

Windows Nano Server не подходит всем подряд. Microsoft специально отмечает, что нацеливает свой продукт на два основных рынка: облачных приложений,
где важна способность работать с разными языками и библиотеками в контейнерах, виртуальных машинах или физических серверах; и на свою инфраструктуру
Cloud Platform, с поддержкой вычислительных кластеров Hyper-V и кластеров хранения на Scale-out File Server.

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

Microsoft пока не объявляет о дате релиза или о принципах лицензирования Windows Nano Server.

По материалам BitTech

• CACS – изолирование холодного коридора, предполагает, что серверные стойки располагаются «лицом» друг к другу, а холодный воздух подается в проход между ними. Сам проход между стойками обычно стараются изолировать различными перегородками сверху и с концов, чтобы избежать перемешивания воздуха.
• HACS – изолирование горячего коридора, предполагает, что серверные стойки располагаются задними стенками друг к другу, горячий коридор также изолируется, оттуда горячий воздух выдувается через систему кондиционирования наружу.

На конференции Build в Сиэттле, генеральный директор Microsoft Сатья Наделла рассказал об облачном сервисе Azure для «интернета вещей», в котором множество сенсоров и небольших устройств могут отправлять данные для последующего анализа их с помощью средств искусственного интеллекта (ИИ).

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

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

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

По материалам Bloomberg 

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

1. «Сильный» пароль на самом деле может предотвратить большинство атак

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

«Я наблюдаю много пренебрежения вопросами безопасности с тех пор, как Сноуден опубликовал секретные документы. Общее мнение примерно такое – мы
ничего не сможем сделать, чтобы быть в безопасности. Это может быть правдой в отношении обычного человека и аппарата разведки уровня
государства, но это не должно мешать людям предпринять необходимые шаги для защиты себя от более реалистичных угроз.

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

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

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

2. Новое устройство – не означает «безопасное»

Когда вы открываете коробку с только что купленным смартфоном или компьютером, вы ожидаете, что он полностью «чист» и безопасен, но
это не так. Элеонора Саитта, технический директор Института современных СМИ, что это самый опасный миф – что новое устройство безопасно,
и только впоследствии, от его использования в разных условиях, оно может подхватить вирус или вредоносное ПО.

«Вот почему Superfish так много значил (это adware, которое предустанавливалось на лэптопах Lenovo). В нем был встроен бэкдор, и но сделано было это очень плохо, и в итоге оказалось, что воспользоваться им может каждый.»

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

«Если какой-то обходной путь встраивается в систему, то вы встравиаете проблему своими собственными руками. Да, вы каким-то образом можете контролировать доступ, но в конце концов – этой уязвимостью может воспользоваться каждый»

3. Самое лучшее ПО содержит уязвимости

Многие люди думают, что хорошее ПО и надежные сети гарантируют защиту. Париса Табриц, руководитель отдела безопасности в Google Chrome, считает следующее:

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

Специалист по компьютерной безопасности корпорации RAND Лиллиан Эблон считает, что не существует абсолютно безопасной системы:

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

4. Каждый вебсайт и приложение должны использовать https

Мы все слышали про какие-то проблемы с https – он замедляет работу, он только для сайтов, которые должны быть супер-безопасными, он плохо работает. Все совсем не так. Питер Экерсли, специалист, который изучал вопросы https для Electronic Frontier Foundation, говорит следующее:

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

5. Облако, как и любая система, не может быть полностью безопасным

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

«Облачные сервисы могут связать данные и поведение своих клиентов – например, мы можем увидеть, что с одного ip-адреса залогинились на несколько аккаунтов, причем из совсем другой страны, чем когда-либо с них логинились»

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

«Сначала я сама обслуживала свой емэйл-сервер, но потом переключилась на хостящийся сервис, потому что знаю, что Gmail или Outlook.com делают это гораздо лучше меня. Но для многих людей возможность наблюдения за их действиями со стороны Агентства национальной безопасности является проблемой, и они обслуживают свои емэйл-сервера самостоятельно»

6. Обновления ПО критически важны для безопасности

Мало что раздражает так, как появляющееся сообщение, что надо что-то обновить в ПО. Но часто это единственное, что стоит между вами и «плохим парнем».

О’Доннелл из компании Сisco говорит следующее:

«Частота обновления ПО редко зависит от введения новых фич в ПО, но больше зависит от того, как компании обнаруживают какие-то новые угрозы, которыми может воспользоваться хакер, чтобы получить доступ к вашей системе»

7. Хакеры – это не всегда преступники

Многие хакеры занимаются своим ремеслом, чтобы сделать системы более надежными. Когда уязвимость установлена, ее можно устранить.

О’Доннелл из Cisco говорит:

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

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

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

8. Кибертерроризм – очень редкая штука

Как правило, самая страшная вещь, которая может с вами случиться, это что кто-то вломится в вашу систему, потому что у вас слабенький пароль. Но почему-то люди как правило думают, что кибератаки это прямо-таки «смертельная» угроза. Но системы восстанавливаются из бэкапов, угрозы изолируются, и никто не умирает. Эблон говорит:

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

9. Darknet и Deepweb – это разные понятия

Эблон отмечает, что в СМИ постоянно путают, что это значит.

«Deepweb относится к той части интернета, которая непроиндексирована поисковыми системами, и соответственно, не может быть найдена через, например, Google. Darknet
– это сети, не являющиеся частью обычного интернета, где пользователям нужно специальное ПО для доступа к ним. Например, Silk Road
и многие противозаконные торговые площадки хостятся на сетях из Darknet таких как I2P или Tor»

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

По материалам Gizmodo

Как это обычно бывает, у этого термина нет устойчивого русского перевода, это что-то вроде «базы данных в оперативной памяти».

Мы все помним известное сокращение ACID, обозначающее требования к транзакционной системе: атомарность, согласованность, изолированность, надежность. Но в мире больших данных,
где постоянно растут требования к объему и скорости обрабатываемых данных, часто жертвуют одним из этих требований, чтобы обеспечить необходимую производительность.
In-memory базы данных – типичный пример такого подхода.

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

В терминах ACID базы данных in-memory конечно жертвуют надежностью, ведь при обесточивании или перезагрузке в них пропадают все данные. Существуют ряд методов, которые позволяют снизить этот риск:

• Снэпшоты (снимки) базы данных в разные моменты времени – фактически эквивалентны бэкапу базы данных на жесткий диск. Недостатком метода является гарантированная потеря части «свежих данных» при каких-то проблемах.
• Логи транзакций записывают все транзакции на жесткий диск и позволяют восстановить данные после перезагрузки.
• Использование NVRAM или NVDIMM – модулей памяти, которые сохраняют свое состояние при пропадании питания, хотя конечно NVDIMM и технология Flash-памяти – это уже какое-то гибридное и безусловно более медленное решение.

Зачем нужны нано-сервера?

Чем HTTP/2 лучше

• Дорога в дата-центр – 1 час минимум
• Взять детали со склада, перейти в серверную, провести работы – 30 минут
• Дорога из дата-центра – 1 час минимум

• Выполнение работы – 50 минут (предположим, что наши сотрудники будут делать это несколько медленнее, чем админ, который знает свое оборудование от и до).
• Стоимость организации связи по услуге «Циклоп» - 600 рублей (300 рублей за 30 минут)

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

Краткое резюме

• Если Ваш сайт является корпоративным «сайтом-визиткой», который никакие персональные данные не собирает, а только призывает пользователей Вам написать или позвонить, то этот закон не имеет к Вам отношения
• Если пользователю вашего Интернет-ресурса хотя бы даже предлагается подписаться на емэйл-рассылку, то собираемые сведения являются «персональными данными», вы — считаетесь «оператором» персональных данных, и обязаны с 01 сентября 2015 года обеспечить их обработку на территории РФ

Нарушителей ждет включение в «черный список» Роскомнадзора, а также другие виды ответственности вплоть до уголовной.

Что надо делать?

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

Наименьший вариант (но весьма рискованный) — до этого срока организовать копирование персональных данных к себе на сервер в РФ и использовать для защиты то, что в Законе не требуется «исключительности» хранения этих данных в РФ (см. об этом ниже)

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

Подробное разъяснение

(предупреждаем, здесь куча юридических определений, отсылок к законам и статьям в них)

Вкратце ситуация такова:

Есть Федеральный закон 152-ФЗ «О персональных данных», принят в далеком 2006 году. Основное, что там нас интересует — это «что такое персональные данные» и кто такой «оператор» персональных данных

Другими федеральными законами в этот закон вносятся изменения, в частности:

• Федеральный закон от 21.07.2014 № 242-ФЗ требует обеспечить обработку персональных граждан РФ на территории РФ
• Федеральный закон от 31.12.2014 № 526-ФЗ переносит срок вступления в силу закона 242-ФЗ на 01 сентября 2015 года (ранее была установлена дата 01 сентября 2016 года)

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

Разберемся, что такое «персональные данные».

Определение данного термина дано в статье 3 Федерального закона от 27.07.2006 N 152-ФЗ (ред. от 04.06.2014) «О персональных данных».

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

Существует широко распространенное заблуждение, о том, что если какие-то данные не позволяют идентифицировать определенное лицо, то такие данные не являются «персональными» и к данному закону отношения не имеют.

В особенности это заблуждение широко распространено среди владельцев различного рода инфобизнесов, собирающих у себя на сайте данные для емэйл-рассылок, как правило, это пары
«имя+емэйл». Емэйл-маркетинг является весьма эффективным инструментом и пользуются им десятки тысяч сайтов, причем зачастую — с использованием зарубежных сервисов емэйл-рассылок — таких как MailChimp, Aweber,
GetResponse и прочих.

Однако если мы просто вчитаемся в определение из закона, то нетрудно прийти к выводу, что определенно, емэйл человека или его имя безусловно «относятся прямо или косвенно к определенному лицу» — ведь это имя и емэйл определенного лица.

В этом же законе дается определение того, кто является «оператором» персональных данных. согласно пункту 2) статьи 3 указанного закона:

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

Это определение также «выбивает из-под ног» такой способ защиты как попытку признать владельца сайта, использующего зарубежный сервис емэйл-рассылки «не-оператором». Часто
высказывают мнение, что владелец сайта не является оператором, поскольку ничего не обрабатывает, а все делает за него, скажем, MailChimp. Увы, ведь владелец сайта как
минимум определяет цели обработки персональных данных и их состав (ведь не сам же MailChimp решил за владельца сайта, что за данные он будет собирать, и что будем им рассылать),
поэтому является «оператором».

Федеральный закон от 21.07.2014 N 242-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части уточнения порядка обработки персональных данных в информационно-телекоммуникационных сетях» требует
хранить персональные данные россиян в России. А именно, в статье 2 Закона определено следующее дополнение статьи 18 исходного закона 152-ФЗ:

«При сборе персональных данных, в том числе посредством информационно-телекоммуникационной сети „Интернет“, оператор обязан обеспечить запись, систематизацию, накопление, хранение, уточнение (обновление, изменение),
извлечение персональных данных граждан Российской Федерации с использованием баз данных, находящихся на территории Российской Федерации, за исключением случаев, указанных в пунктах 2, 3, 4,
8 части 1 статьи 6 настоящего Федерального закона»

Сразу скажем, что ничего полезного, что помогло бы избежать исполнения Закона в указанных исключениях — в пунктах 2, 3, 4, 8 части 1 статьи 6 закона 152-ФЗ — нет.

Единственной просматриваемой «лазейкой» (очень слабой), которая может хотя бы потенциально быть использована для защиты, в случае, если владелец сайта продолжит использовать зарубежные
сервисы, является упоминание того, что эти операции должны осуществляться «с использованием баз данных, находящихся на территории Российской Федерации», а не ИСКЛЮЧИТЕЛЬНО на территории Российской Федерации.
Иными словами, если владелец сайта регулярно копирует на свой сервер на территории РФ список собранных емэйл-адресов, то он может утверждать, что он осуществляет указанную деятельность С ИСПОЛЬЗОВАНИЕМ
баз данных на территории РФ, хотя и НЕ ИСКЛЮЧИТЕЛЬНО таких. А запрет на «трансграничную передачу» — это тоже понятие из закона 152-ФЗ — нигде не установлен.

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

И наконец Федеральный закон от 31.12.2014 № 526-ФЗ переносит (приближает) срок вступления в силу закона 242-ФЗ на 01 сентября 2015 года.

Вероятно, ближе к сроку вступления в действия закона, мы увидим какие-то дополнительные разъяснения от законодателей или Роскомнадзора. Пока же наиболее разумным кажется действительно к 1 сентября
2015 года исключить обработку персональных данных зарубежными сервисами, чтобы избежать претензий правоохранительных органов.

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

Лица, виновные в нарушении требований Федерального закона 152-ФЗ «О персональных данных», несут: гражданскую, уголовную (см. Уголовный кодекс Российской Федерации, ст.137, 140, 155, 183,
272, 273, 274, 292, 293), административную (см. Кодекс Российской Федерации об административных правонарушениях, ст. 5.27, 5.39, 13.11–13.14, 13.19, 19.4–19.7, 19.20, 20.25, 32.2)
и дисциплинарную (см. Трудовой кодекс Российской Федерации, ст.81; ст.90; ст.195; ст.237; ст.391) ответственность соответственно тяжести совершенного правонарушения.

Терроризм в big data

Big data становится предметом обсуждения в части гражданских свобод

Открытые данные правительства

Персонализированная медицина

Цифровое образование

Коммутация

Управление производительностью приложений

Безопасность

Российские реалии – перенос серверов и российские облачные сервисы

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

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

• Слабо предсказуемая задержка при больших объемах «горизонтального трафика»
• Проблемы с производительностью при отказе на уровне агрегации
• Сложности с масштабированием

Так как же организовать сеть, если у вас много «горизонтального» трафика, например, между различными серверами? На помощь приходит конфигурация «ствол
и листья» иногда еще такую конфигурацию называют «распределенным ядром», а на английском как правило используется «spine and leaf» или «leaf-spine».
Вендоры также часто используют слова «Ethernet fabric» («ткань Ethernet») – это то же самое.

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

Плюсы такой конфигурации следующие:

• Горизонтальный трафик между «листьями» гарантированно идет с одним хопом, через «дерево», из-за чего задержка становится предсказуемой
• При отказе оборудования, меньше страдает производительность, а устранение отказов легче, поскольку оборудование однородно
• Масштабировать такую конфигурацию, очевидно, легче

В статье использованы материалы Network Surgeon и TechTarget.

1. 1 сервер 4 U
2. Потребление электроэнергии 250 Вт.
3. 5 IP адреса
4. I-net 50 Мбит/с

1. 4 сервера по 1U
2. 500 Вт на всех
3. 5 IP адреса
4. I-net 50 Мбит/с

• Corsair Neutron GTX
• Intel 335 Series
• Kingston HyperX 3K
• Kingston HyperX 3K (со сжатием)
• Samsung 840
• Samsung 840 Pro

CDN (content distribution network), или говоря по-русски, «сеть доставки контента», представляет собой сеть географически распределенных серверов. С их помощью, пользователю предоставляется доступ к контенту сайта или приложения в зависимости от его местоположения.

Как всем известно, скорость доступа к сайту достаточно сильно зависит от того, насколько далеко пользователь находится от того сервера, где
сайт размещен. А если быть точнее – сколько различных маршрутизаторов находятся между ним и сервером. Отсюда, при прочих равных условиях,
один и тот же сайт, размещенный в Москве, будет «работать быстрее» для жителя Москвы, по сравнению с таким же сайтом,
расположенным на Дальнем Востоке.

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

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

Потребность в реализации CDN конечно не требует от владельцев или админа сайта реализовывать все самостоятельно. И в мире и в
России достаточно большое количество провайдеров CDN, чей сервис можно использовать. В этом бизнесе присутствуют как небольшие игроки, так и настоящие
гиганты – Akamai, Amazon CloudFront, Windows Azure CDN, HP Cloud Services.

Во многих новых роутерах появилась такая функция как beamforming (обычно переводится как «формирование луча» или
«концентрирование излучения»). Иногда ее называют «spatial filtering» (пространственное фильтрование). Расскажем, что это такое.

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

В стандарте 802.11n оба устройства, например роутер и компьютер, должны использовать один и тот же тип этой технологии (как правило это достигается использованием продуктов одного и того же производителя – роутера и 802.11n-брелка в ноутбуке), иначе не будет эффекта.

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

Технология эта бывает в «явной» и «скрытой» реализации (explicit и implicit в англоязычных источниках). В «явном варианте» оба источника обмениваются
информацией друг с другом о радиоканалах, и их местоположении друг относительно друга. В «скрытом» варианте, роутер пытается это сделать самостоятельно
– не получая дополнительной информации от подключенного другого устройства. Очевидно, что первый вариант дает больший выигрыш, поскольку более эффективен.

Какие посадочные страницы нужны, сколько?

• Через проверку некоторых ключей в регистре, характерных для виртуальных систем
• Через проверку, установлено ли ПО типа VMWare Tools
• Через проверку определенных процессов и наименований служб
• Через проверку коммуникационных портов и их поведения
• Запуская специальный код на ассемблере и сравнивая его исполнение
• Через проверку размещения системных структур, как например, дескрипторных таблиц

Среди различных показателей производительности SQL-сервера есть Page Life Expectancy. По-русски, это «ожидаемый срок жизни страниц», и дальше мы будем называть его просто PLE для краткости.

Этот параметр показывает сколько в среднем времени страницы находятся в буфере (в секундах).  Фактически этот параметр демонстрирует уровень нагрузки, связанной с вводом-выводом, на ваш SQL-сервер. Поскольку проблема физического расширения ввода-вывода непроста, за этим параметром надо следить.

Суть параметра проста – чем выше PLE, тем больше шансов, что при обращении к данным, они найдутся в буфере, и не придется обращаться к жесткому диску, чтобы прочитать их. Таким образом производительность сервера остается на высоком уровне.

Какой должен быть этот параметр? Как базовый уровень, принято считать, что если PLE меньше 300, тогда надо начинать разбираться, почему он такой низкий. На слабонагруженных серверах он может превышать и 1000 и больше.

И еще, важно не забывать о том, что если вы используете сервер с большим количеством узлов NUMA, то важно смотреть не на общий PLE, а на PLE по каждому узлу буфера, потому что проблема на одном (падение в разы) может не вызвать значимого изменения общего PLE.

Любые рассуждения насчет собственных серверов и серверных для малого и среднего бизнеса будут неполными, если не принимать во внимание такое понятие как TCO (total cost of ownership — совокупная стоимость владения).

Этот термин означает общую величину затрат, которые вынужден нести владелец. Фактически это сумма начальных, как правило, капитальных затрат (CapEx) на помещение и оборудование и операционных затрат на обеспечение работоспособности.

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

Рассмотрим, о чем часто забывают при оценке решения «своя серверная»:

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

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

Само слово «целостность» имеет несколько смыслов в мире SQL. Один из них относится к качеству данных, хранящихся на сервере. В
другом смысле, целостность поддерживается через правильный ввод данных, ограничения на вводе, и проверку данных. В третьем смысле, целостность относится к
логическому и физическому постоянству структуры базы данных – это гораздо более сложная тема, к которой как раз и относится данная
статья.

В SQL-сервере есть команда DBCC, чтобы проверять целостность базы. Существует несколько вариантов этой команды, но сейчас мы поговорим только про DBCC CHECKDB. Эта команда проверяет внутренние структуры, метаданные, и данные в базе.

В своей простейшей форме команда выполняется в следующем формате: DBCC CHECKDB (имя базы данных);

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

• NO_INFOMSGS: убирает все информационные сообщения
• ALL_ERRORMSGS: возвращает ВСЕ сообщения об ошибках. В ранних версиях SQL-сервера, сообщения об ошибках ограничивались 200-ми. Если запустить команду через SSMS (SQL Server Management Studio), ограничение будет равно 1000. Эта опция выдает все сообщения.
• TABLERESULTS: возвращает результаты в удобной таблице, нежели в обычном тексте.

Когда команда обнаруживает проблему, легко запутаться в том, что она выдает. Для начала самое главное – это посмотреть на колонку «Уровень».  Уровень показывает серьезность проблемы, и в первую очередь вам надо смотреть на проблемы с самым высоким уровнем 16.

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

И последний совет, игнорируйте столбец RepairLevel, не используйте функции восстановления для CHECKDB, пока абсолютно все другие средства не были использованы
и не помогли. Функция восстановления (repair) удалит страницы с данными, содержащими повреждения, и потом их нельзя будет восстановить, кроме как
вручную ввести данные. Если вы не являетесь экспертом по работе с повреждениями в базе данных, найдите такого эксперта, перед тем,
как пытаться как-то исправить проблему.

По материалам sqlsoldier.com

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

Что такое базы данных временных рядов и почему потребовалось создавать специализированные БД, если есть достаточное количество серьезных промышленных систем управления базами данных: Oracle, MS SQL Server, Sybase и много других? Чтобы ответить на этот вопрос, необходимо понять, что составляет предмет этих БД.

Такого рода данные требуются и накапливаются при самых разных задачах и для самых разных нужд. Можно привести несколько примеров:

• статистика использования сайта (посещения сайта, аппаратных и сетевых ресурсов и т.д.);
• финансовая, биржевая, актуарная статистика;
• макроэкономическая статистика.

Иными словами, спрос на инструменты для хранения и обработки данных временных рядов достаточно высок (особенно со стороны финансового рынка).  Однако
пользователи крупных СУБД столкнулись с проблемой: универсальные монстры оказались слабо приспособлены для решения именно таких задач, и проблема вырастала из
идеологии (модели данных) наиболее распространенных в то время реляционных баз данных,  не позволяющей эффективно работать с упорядоченным множеством элементов временного
ряда. Появились разработки специализированного программного обеспечения, оптимизированного под эти задачи.

Базы данных временных рядов (time series database) позволяют пользователям создавать, считать, обновлять и удалять различные временные ряды и организовывать их
неким образом. Сервер часто поддерживает ряд основных вычислений, которые работают на ряды в целом, например, умножая, складывая или иным образом
комбинируя различные временные ряды в новый временной ряд. Они могут также фильтровать по произвольным образцам, при этом значения одного ряда
могу являться фильтром для другого. Простой синтаксис является залогом привлекательности специальных баз данных временных рядов.

Среди специальных TSBD преобладают продукты, основанные на свободной лицензии: Open TSDB, InfluxDB, Geras, Druid и пр. Некоторые из них «заточены» под  относительно узкий спектр задач. Так, YAWNDB и SiteWhere позиционируются как инструмент для специалистов в области веб-технологий.

Реализация функционала базы данных временных рядов возможна в обычной реляционной БД на основе SQL при условии, что программное обеспечение базы
данных поддерживает одновременно большие двоичные объекты (BLOB) и пользовательские функции.  Но эффективность такой системы также будет невысока. Поэтому разработчики крупных
баз данных пытаются развить реляционную модель данных до объектно-реляционной, обладающей частью свойств объектно-ориентированной БД, в частности, в поддержке концепции абстрактного
типа данных. Например, IBM предлагает оптимизированный продуктом Informix Time Series.

Когда говорят «top-of-rack» и «end-of-row» в отношении коммутаторов, речь идет о двух видах коммутационной инфраструктуры.

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

Итак, top-of-rack — это модель коммутации, когда в каждой стойке стоит коммутатор, который обрабатывает трафик с серверов в этой стойке, и соединен с коммутатором ядра или
с агрегирующим слоем (в зависимости от количества уровней). Хотя и устоялось название top-of-rack — не утверждается, что именно в верхней части стойки должен физически располагаться коммутатор. Говорят,
что изначально это было так, потому что админы предпочитали сначала воткнуть все кабели в коммутатор, чтобы потом больше к нему не прикасаться. И тогда,
если коммутатор вверху, кабели удобно свешиваются вниз и облегчают подключение.

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

У top-of-rack есть и недостатки, которые станут заметными, когда количество стоек в дата-центре вашей компании будет серьезно расти. Если предположить, что у вас скажем
20 стоек, в каждой из которых стоит по 2 коммутатора, то это 40 коммутаторов, а с точки зрения обслуживания — это уже не просто. Это 40 копий софта для
коммутатора для обновления, 40 конфигурационных файлов, которые надо создать и надежно архивировать, иными словами — 40 мест, где «что-то может пойти не так».

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

Модель коммутации end-of-row предполагает расположение коммутатора, условно, «в конце ряда стоек» и обслуживание им трафика с со всех серверов из нескольких стоек, расположенных в ряд. Опять же физически
это не значит, что коммутатор должен быть почему-то именно в последней стойке. Такое расположение было принято для дублирующих коммутаторов, которые изначально действительно
располагали в разных концах ряда стоек, чтобы например какая-то внезапная проблема типа протекшей крыши в одном месте, не вырубила из работы целый ряд стоек.

В такой схеме серверы в стойке обычно соединяются относительно короткими RJ-45 кабелями с коммутационной панелью в стойке, от которой идет плотный пучок кабелей, как правило через верх, над серверными стойками, к end-of-row коммутатору.

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

В предыдущем примере, если мы условно возьмем по 10 стоек в ряд, то для 20 стоек понадобится всего 4 end-of-row коммутатора, в отличие от 40 коммутаторов в случае
с top-of-rack конфигурацией. То есть с точки зрения поддержки — это в 10 раз меньше потенциальных забот. Это, пожалуй, главное достоинство такой схемы.

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

В то же время неверно думать, что end-of-row даст существенную экономию капитальных затрат. Например 48-портовая карта для end-of-row коммутатора может стоить примерно
столько же, сколько и 48-портовый коммутатор, который Вы бы поставили в стойку при top-of-rack решении. Возможная экономия может быть в обслуживании, поскольку обслуживать существенно меньшее
количество end-of-row коммутаторов окажется все-таки проще.

• Общее назначение: DNS, Radius, OpenVPN, Apache, MySQL, Squid
• Microsoft: MCITP MS Server 2008, MCSA MS Server 2012, MCITP MS Exchange 2010
• Linux: Виртуализация KVM, Open Stack, CEPH
• Мониторинг: Cacti, Nagios,
• Поддержка сетевого оборудования: Cisco, Juniper, Mikrotik на уровне CCNP
• Телефония: Asterisk

Часто при выборе определенного сетевого устройства для вашей сети, можно услышать такие фразы как «коммутатор уровня L2», или «устройство L3».

В этом случае речь ведется про уровни в сетевой модели OSI.

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

Устройства уровня L2 работают на канальном уровне и выполняют физическую адресацию. Работа на этом уровне выполняется с кадрами, или как
иногда еще называют «фреймами». На этом уровне нет никаких ip-адресов, устройство идентифицирует получателя и отправителя только по MAC-адресу и передает
кадры между ними. Такие устройства как правило называют коммутаторами, иногда уточняя, что это «коммутатор уровня L2».

Устройства уровня L3 работают на сетевом уровне, который предназначен для определения пути передачи данных, и понимают ip-адреса устройств, определяют кратчайшие
маршруты. Устройства этого уровня отвечают за установку разного типа соединений (PPPoE и тому подобных). Эти устройства обычно называют маршрутизаторами, хотя
часто говорят и «коммутатор уровня L3».

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

Как часто бывает, словам «columnar database» или «column-oriented database» еще не подобрался стандартный русский перевод. Иногда говорят «столбцовая база данных», иногда встречается перевод «колончатая».

Что же такое «столбцовая база данных», и что нового в таком подходе?

Большинство современных реляционных баз данных являются «строчными», то есть данные, хранящиеся в базе данных в виде таблицы, со строками и столбцами, записываются на диск построчно.

Как вы, вероятно знаете, самая «дорогая» в плане быстродействия операция, которую совершает жесткий диск, это так называемый «seek» — операция позиционирования головки
жесткого диска. Если данные в базе записаны на диск построчно, то как правило за чтение одного блока, будет считана вся строка с данными. Поэтому при
построчной записи данных, минимизируется время на чтение одной записи в базе данных о каком-то объекте, например, о сотруднике, в базе сотрудников — то есть все его хранимые
данные, Ф.И.О., год рождения, и так далее.

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

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

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

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

Хотя эффективность базы данных разных типов (строчной или столбцовой) очень сильно зависит от задач и типичных сценариев их использования, можно утверждать, что как правило:

• Столбцовые базы данных более эффективны в случаях, когда часто требуется вычислять какие-то совокупные величины — средние, суммы, и прочие по каким-то значениям.

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

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

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