Реляционные базы данных (РБД) используются повсюду. Они бывают самых разных видов, от маленьких и полезных SQLite до мощных Teradata. Но в то же время существует очень немного статей, объясняющих принцип действия и устройство реляционных баз данных. Да и те, что есть — довольно поверхностные, без особых подробностей. Зато по более «модным» направлениям (большие данные, NoSQL или JS) написано гораздо больше статей, причём куда более глубоких. Вероятно, такая ситуация сложилась из-за того, что реляционные БД — вещь «старая» и слишком скучная, чтобы разбирать её вне университетских программ, исследовательских работ и книг.

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

До недавнего времени в Одноклассниках в качестве основного Linux-дистрибутива использовался частично обновлённый OpenSuSE 10.2. Однако, поддерживать его становилось всё труднее, поэтому с прошлого года мы перешли к активной миграции на CentOS 7. На подготовительном этапе перехода для CentOS были отработаны все внутренние процедуры, подготовлены конфиги и политики настройки (мы используем CFEngine). Поэтому сейчас во многих случаях миграция с одного дистрибутива на другой заключается в установке ОС через kickstart и развёртывании приложения с помощью системы деплоя нашей разработки — всё остальное осуществляется без участия человека. Так происходит во многих случаях, хотя и не во всех.

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

В настоящей статье я попробовал в максимально доступном и сжатом виде описать что такое IKEv2, FlexVPN и как это реализовано в IOS маршрутизаторов Cisco. Для наилучшего понимания содержания, нужно чтобы читателя, на момент ознакомленимя с нижеприведенным текстом, не пугали такие слова как VPN, IPSec, ISAKMP, ISAKMP Profile и т.д. Кроме того, желательно иметь хорошее представление о том, как настраиваются различные типы VPN с использованием VTI интерфейсов (или GRE over IPSec) на оборудовании Cisco, поскольку статья в значителной степени опирается на знание этих вопросов.

Предисловие

Сразу нужно акцентировать внимание, что не надо думать, что IKEv2 является чем-то совсем новым, сложным для понимания и полностью меняет всю концепцию построения VPN-сетей. IKE(как 1 так и 2) призваны лишь для того чтобы обеспечить ESP (ну или AH, если кому-то нужно) необходимой ключевой информацией, нужной указанным протоколам для непосредственной защиты данных. Сам же ESP, его режимы работы (tunnel/transport) и все связанные понятия не меняются.

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

Недавно я переосмыслил процедуру установки нового сервера Puppet с нуля на Ubuntu 12.04, включая все современные свистелки и перделки. В итоге у меня получился этот гайд.

Для начала нам потребуется чистая Ubuntu c работающей сетью и настроенным DNS.

В итоге мы должны получить:

• Установленый везде Puppet 3-й версии
• Конфиги в git репозитории с общим доступом
• Динамические окружения, управляемые r10k
• Поддержку PuppetDB
• Поддержку Hiera

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

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

Недавно наткнулся на полезную и очень подробную статью Adaptec, которая описывала ну просто все нюансы работы контроллеров, пугал разве что объем в 60 страниц. Возникло естественное желание сократить и разделить статью на 2 куска:

• Часть 1. Общие сведения о RAID контроллерах (много теории, азы)
• Часть 2. Классификация контроллеров Adaptec (здесь всё очень конкретно – серии контроллеров, функции каждой серии, таблицы, картинки)

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

Собственно, Часть 1.

Проштудировав документы Perfomance Best Practices for vSphere 5.5 и Perfomance Best Practices for vSphere 6.0, не выявил особых расхождений в настройке, как и чего-то дополнительно специфичного для vSphere 6.0.

Большая часть написанного умещается в стандартные рекомендации формата «используйте совместимое и сертифицированное оборудование» и «при сайзинге ВМ выделяйте ресурсы (vCPU, vRAM) в объёме не более необходимого».

Тем не менее, базовые вещи решил оформить отдельным постом, немного переструктурировав, избавив от «воды» и некоторых отсылок и замечаний, которые являются слишком специфичными и для большинства реализаций являются скорее вредными чем полезными. В сухом остатке остались рекомендации, советы и соображения, проверенные и протестированные на практике и применимые для 90% инфраструктур VMware vSphere и standalone ESXi. Разбавленные общими соображениями и дополнениями.

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

Материал разбит следующим образом:

1. Введение
2. Примеры сессий
3. Проверка авторизации на сервере (LOGIN, PLAIN, CRAM-MD5), Base64
4. Проверка шифрования SSL/TLS
5. Анализ почтового трафика при помощи tshark. Расшифровка SSL/TLS
6. Ссылки на материалы

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

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

У нас нет денег и мы все делаем за свой счет, поэтому экономим. Итог — весь миллион клиентов обслуживается на одном сервере, вот на таком — EX-60 на hetzner.

Вот уже как неделю английская версия the art of command line висит в секции trending на Github. Для себя я нашел этот материал невероятно полезным и решил помочь сообществу его переводом на русский язык. В переводе наверняка есть несколько недоработок, поэтому милости прошу слать пулл-реквесты мне сюда или автору оригинальной работы Joshua Levy вот сюда. (Если PR отправите мне, то я после того, как пересмотрю изменения отправлю их в мастер-бранч Джоша). Отдельное спасибо jtraub за помощь и исправление опечаток.

Привет, Хабр!

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

И о том, как порой тяжело найти что-то одновременно простое, функциональное и надежное?
Когда первый раз настраиваешь динамическую маршрутизацию, тебе кажется, что ты близок к правде и пониманию того, как устроены сети. Но стоит новичку взглянуть на рабочий конфиг серьезной операторской сети, как становится понятно, что мир не заканчивается командой «network».

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

Но не все так страшно! Уделите внимание литературе, спросите про шишки более мудрых камрадов, и дзен станет ближе.

Вашему вниманию я предлагаю последний выпуск про IS-IS!

В этом выпуске:

• Ешь, пей в аду. Пиши сценарий к IS-IS.
• Почему OSPF сильнее Супермена?
• Что будет в OSPFv4?*
• Overload bit и iSPF — сложнее объяснить, чем сделать.
• BFD. Молниеносный убийца вашего CPU.
• Почему Горден Фримен радуется, когда вы настраиваете dampening?
• Алгоритм экспоненциального откладывания или история про жадного ребенка.
• Сходимость и циферки!
• Как несчастный IGP ждал LDP. Жалко я не вспомнил Хатико.

*понятия не имею, но расскажу.



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

Предыдущие части

• Часть первая — habrahabr.ru/post/255361
• Часть вторая — habrahabr.ru/post/255523
• Часть третья — habrahabr.ru/post/255825
• Часть четвертая — habrahabr.ru/post/256045

В данной части мы рассмотрим

Здесь мы в общих чертах рассмотрим работу с операторами модификации данных:

• INSERT – вставка новых данных
• UPDATE – обновление данных
• DELETE – удаление данных
• SELECT … INTO … – сохранить результат запроса в новой таблице
• MERGE – слияние данных
• Использование конструкции OUTPUT
• TRUNCATE TABLE – DDL-операция для быстрой очистки таблицы

В самом конце вас ждут «Приложение 1 – бонус по оператору SELECT» и «Приложение 2 – OVER и аналитические функции», в которых будут показаны некоторые расширенные конструкции:

• PIVOT
• UNPIVOT
• GROUP BY ROLLUP
• GROUP BY GROUPING SETS
• использование приложения OVER

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

Что-то в последнее время технические статьи о виртуализации (да и не только о виртуализации) скатываются к формату «в новой версии ожидается такая фича». Складывается ощущение, что разбор механизмов и описание опыта, проблем и решений интересны только зарубежным экспертам. С другой стороны, есть такая проблема у экспертов — если что-то изучил, оно становится элементарным и воспринимается само собой разумеющимся, настолько, что писать об этом как-то глупо. Особенно если уже было кем-то описано где-то. Когда-то. На каком-то языке. Ниженаписанное — плод консолидации личных заметок, сначала предназначавшийся для личного упорядочивания мыслей, но наупорядочив значительный объём текста, подумал, что кому-то может пригодиться.

Типовая проблема «виртуализаторов» — владелец сервиса, заказчик или пользователь жалуется, что у него «тормозит» виртуальная машина. Так как виртуализация предполагает консолидацию большого количества ВМ на базе одного комплекта аппаратных ресурсов, переподписку (overprovision — когда мы предполагаем, что серверы не затребуют одновременно максимум своих ресурсов, а значит, например, в 40 ГБ физической памяти мы можем натолкать не 10 серверов по 4 ГБ RAM, а 15, используя Dynamic Memory), а кроме того, серверы могут тормозить и из-за ошибок в программных компонентах и их настройках, то каждый раз приходится решать за что хвататься и куда смотреть в первую очередь. Особенно, если с таким ёмким описанием проблемы, как «тормозит машина» не предоставлено никакой диагностической информации, как чаще всего и бывает. Под катом небольшое руководство для этого случая.

Загрузочная флешка с набором нужного софта — замечательный инструмент системного администратора. Казалось бы, что может быть лучше? А лучше может быть загрузочный сервер!

Представьте, вы выбрали в BIOS загрузку по сети и можете установить ОС/вылечить компьютер от вирусов/реанимировать диски/протестировать ОЗУ/etc с PXE Boot сервера, ведь это куда удобнее, нежели бегать с флешкой от машины к машине.
А в случае большого компьютерного парка, такой инструмент и вовсе незаменим.

Вот такое меню встречает нашу команду инженеров при загрузке с PXE



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

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

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

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

Привет, гиктаймс!

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

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

В статье рассматривается построение простейшей сети с несколькими провайдерами и клиентами, в частности, такие технологии, как NAT, OSPF, BGP, MPLS VPN. Многое, естественно, будет не учтено. Например в статье почти нет описания проблем безопасности, т.к. на эту тему можно говорить бесконечно, а текст и так получается довольно объемным. QoS тоже оставлен в стороне, т.к. в лабораторных условиях его особо не проверишь.

По поводу целевой аудитории. Совсем новичкам в сетях статья, боюсь, будет непонятна. Людям, обладающим знаниями хотя бы на уровне CCNP – неинтересна. Поэтому я примерно ориентируюсь на сертификацию CCNA R&S.

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

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

Сразу оговорюсь, «преодолевал» в названии отражает только тот факт, что теперь моя XP видит всю память, установленную на системной плате. Не я придумал способ, я просто им воспользовался и теперь хочу поделиться.
Вопрос о четырёх гигабайтах памяти в Windows XP (здесь, и далее 32 бит) поднимался на просторах Интернет неоднократно. И так же неоднократно делался вывод, что более четырёх увидеть в принципе невозможно, а так как оборудование тоже требует адресного пространства, то и того меньше. Обычно 3.25 Гб, или около того. Очень подробно и убедительно история вопроса освещена здесь: Четыре гигабайта памяти — недостижимая цель?

Меня этот вопрос тоже волновал. Хотя, казалось бы, можно поставить 64 битную систему, или даже Windows Server (как известно он даже в 32-битной версии видит всю память), но я хотел пользоваться Windows XP. Два раза за последние 3 года я переходил на Windows 7, в первый раз на 64-битную, второй раз на 32-х битную, но в итоге оба раза вернулся назад на XP, которая живёт у меня без переустановки с 2007 года.
Последний раз я отказался от семёрки в пользу старушки буквально две недели назад. Притом, надо отметить, что семёрка была хоть и 32-х битная, но в ней была разблокирована возможность видеть всю доступную память. Способ разблокировки доступен в Интернет. И теперь мне с новой силой захотелось решить этот вопрос и в XP.

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