Примечание переводчика: В нашем блоге мы много пишем о построении облачного сервиса 1cloud (например, о реализации функции управления дисковым пространством сервера на лету), но немало интересного можно почерпнуть и из опыта по работе с инфраструктурой других компаний. Мы уже рассказывали о дата-центре фотосервиса imgix, описывали детективную историю поиска проблем с SSD-дисками проекта Algolia, а сегодня представляем вашему вниманию адаптированный перевод заметки о модернизации дата-центра Stack Exchange (осторожно, много фото!)
Несколько недель назад мы обновили базовую инфраструктуру нашего дата-центра в Нью-Йорке (ладно, теперь он в Нью-Джерси, но это пока секрет). Мы не любим ничего скрывать (включая инфраструктуру) и считаем открытость важнейшим благом нашей работы. Вот история о том, как мы модернизировали наш дата-центр. Для начала взгляните, с чего начинался Stack Overflow – фотографии сделаны 5 лет назад, а с того момента в сфере аппаратного обеспечения многое изменилось.
Мы не меняли ни единого сервера со времен апгрейда начальной конфигурации веб-серверов – в этом просто не было нужды с тех пор, как мы переместили наш дата-центр в Нью-Йорк (это случилось 23 октября 2010 года – больше 4 лет назад). Мы всегда реорганизуем, настраиваем и проверяем наше оборудование, а также оптимизируем код и инфраструктуру, когда это возможно. Чаще всего мы делаем это с целью увеличить скорость загрузки страниц – снижение нагрузки на ЦПУ и снижение объёма занимаемой памяти веб-сервера чаще проявляются как побочный (но чрезвычайно полезный) эффект.
Что случилось? Мы провели встречу. В октябре прошлого года все инженеры Stack Exchange собрались вместе в штаб-квартире в Денвере и приняли серию решений. На той встрече мы ограничили жизненный цикл аппаратной части, посчитав это выгодным с экономической точки зрения. Тогда было установлено, что аппаратное обеспечение должно эксплуатироваться примерно 4 года. По истечении этого времени оно списывается, заменяется или эксплуатируется еще какое-то время – такой подход позволяет упростить планирование. Например, мы ограничили себя двумя поколениями серверов, после которых мы не продлеваем на них гарантию (разве что, только в исключительных ситуациях), и теперь мы можем заказывать «железо» заранее, сразу оформляя четырехлетнюю гарантию.
Почему 4 года? Цифра взята с потолка? Что ж, так и есть. В тот момент у нас работало оборудование четырехлетней давности и вполне справлялось со своими задачами. Вот и все, зачем что-то выдумывать? Большинство компаний списывают аппаратное обеспечение через три года, упрощая ответ на вопрос: «Что нам с ним делать?». Списанное оборудование означает, что оно снято с учета, и мы можем направить его на другие цели, продать или просто отдать сотрудникам на растерзание. Знаете, не так давно нам удалось привлечь немного денег. Хоть конечные суммы не были озвучены на встрече в Денвере, мы знали, что в 2015 году будет производиться замена оборудования.
За два месяца мы подсчитали количество оборудования старше 4 лет (или приближающегося к этой цифре по возрасту). Оказалось, что все 11-е поколение нашего оборудования марки Dell (включая решения для веб-уровня) подошло под этот критерий – потому было принято решение заменить все поколение, решив массу управленческих проблем одним махом. Управление только 12-м и 13-м поколениями программного и аппаратного обеспечения упрощает жизнь в целом. К тому же, обновление программного обеспечения позволяет поднять уровень производительности 12-го поколения до 13-го (конца апреля 2015 года).
За эти два месяца мы поняли, что используем очень много старых серверов (большинство из них функционируют с мая 2010 года):
У нас имелось дополнительное место, чтобы разместить новые серверы, поэтому добавим в список:
Получилось довольно много серверов под замену. Как много? Вот столько:
Я знаю, что вы думаете: «Ник, как вы начали модернизировать такую разнородную гору серверов?» Я рад, что вы спросили. Вот вам история модернизации инфраструктуры Stack Exchange в оперативном дата-центре. Мы решили не использовать функцию аварийного переключения для проведения апгрейда, вместо этого мы использовали множество резервных блоков, через которые временно шел трафик.
День -3 (Вторник, 22 января): Наш план апгрейда был готов (на это ушло порядка полутора дней) и учитывал все аспекты, которые нам пришло в голову обсудить. Мы были ограничены по времени непосредственных работ в дата-центре, поэтому расписали и продумали все заранее (большинство пунктов прошло по плану). Полный план вы можете найти здесь.
День 0 (Воскресенье, 25 января): Сисадминами, которые непосредственно занимались апгрейдом, были Джордж Бич (George Beech), Грэг Брей (Greg Bray) и Ник Крэйвер (Nick Craver) (следует отметить, что несколько системных администраторов выполняли свою работу удаленно, и их вклад в работу был не меньшим: Джефф Дэлгас (Geoff Dalgas) работал из Карвелиса, Шейн Мадден (Shane Madden) – из Денвера, а Том Лимончелли (Tom Limoncelli), который очень помог с планированием, – из Нью-Джерси). Сразу после начала работ мы получили предупреждение о снегопаде, поэтому перед отъездом в Нью-Йорк упаковали теплые вещи.
День 1 (Понедельник, 26 января): Хотя наш офис находится в нижней части Манхеттена, дата-центр располагается на другой стороне реки Гудзон в Джерси-Сити:
Мы знали, что нас ждет гора работы. Проблема была в том, что если мы поедем в понедельник, то, вероятно, не сможем вернуться в дата-центр во вторник, так как линию метро до Нью-Джерси закроют. Так и произошло. Но команда решила начинать работу. Мы прихватили с собой все, что нужно, чтобы заночевать на месте, и направились в дата-центр. Вот что ждало нас там, в ожидании установки:
Да, мы были взволнованы! Перед тем, как начать апгрейд, нам нужно было решить важную задачу с серверами Redis, занятыми объявлениями Targeted Job. Эти машины изначально управлялась Cassandra (мы отключили это хранилище), а затем Elasticsearch (и его тоже отключили), теперь они работали под управлением Redis. Как мы ими распорядились? Джейсон Паньон (Jason Punyon) и Кевин Монро (Kevin Montrose) ведут интересный блог о нашем проекте Providence. Вы можете найти пост Паньона, в котором он рассказывает, что произошло с каждым из этих хранилищ.
Для этих систем были заказаны жесткие диски Samsung 840 Pro, которые, как выяснилось, имеют серьёзный баг в прошивке. Из-за этого бага копирование с сервера на сервер в дублированной 10-гигабитной сети производилось на скорости 12 МБ/сек (ух!). Если учесть, что в экземплярах Redis хранятся сотни гигабайт, то можно сказать, что для нас это было неприемлемо. Нам нужно было обновить прошивку дисков, чтобы восстановить работоспособность и перестроить массивы RAID10. Поскольку через большую часть USB-интерфейсов обновить прошивку нельзя, мы разобрали на части бедную машину, чтобы осуществить задуманное:
Когда процесс был запущен, он шел в фоновом режиме, параллельно с другой работой (поскольку для перестроения массива RAID10 с данными на борту требуется несколько десятков минут, даже если используется диск SSD). В результате удалось увеличить скорость копирования файлов до 100-200 Мбайт/сек (мы вскоре столкнемся с еще одной проблемой – нужно еще многое настроить). Теперь начинается самое интересное. В серверной стойке С (мы очень уважительно относимся к нашим стеллажам и даем им буквенные имена) мы хотели заменить подключение SFP+ 10 Гбит с шириной внешнего канала 1 Гбит на интерфейс 10GBASE-T (разъем RJ45). Это делалось по нескольким причинам: кабель, используемый для SFP+, называется твинаксиальным: его очень сложно прокладывать и непросто напрямую подключить к дочерним картам серверов Dell. Также, SFP+ FEX не позволяют подключать устройства стандарта 10GBASE-T, которые могут появиться позднее (именно в этой стойке их нет, но они могут быть в других, например, в распределителе нагрузки). Вот, что было установлено в стойке С:
Мы хотели прийти к этому:
В планах было упростить конфигурацию сети, уменьшить количество кабелей и количество элементов в целом, при этом сэкономив 4U свободного пространства. Вот так выглядела верхняя часть стойки, когда мы начали:
…а это её средняя часть (уже без кабель-организатора):
Самое время начинать. Во-первых, нам нужно было, чтобы KVM продолжали работать, поэтому мы их… «временно переместили»:
Теперь, когда нам ничего не мешает, самое время спустить SFP+ FEX вниз, чтобы мы могли установить новые 10GBASE-T FEX на свое место:
Принцип работы технологии FEX позволяет нам выделить от 1 до 8 uplink портов для каждого коммутатора. Это означает, что мы можем отключить четыре порта от каждого FEX, не прерывая работу сети, затем взять четыре из них, отключенные от VPC, и переназначить на новое устройство. В ходе апгрейда схема подключения будет изменяться следующим образом: 8/0 -> 4/4 -> 0/8. Фотография в середине данного процесса:
Новая сеть готова – можно начинать установку серверов: несколько старых мы выдернули, так как один был виртуализирован, а два других уже были не нужны. Дополнительно были ликвидированы хосты NY-VM01 и NY-VM02, что позволило освободить место на стойке в размере 5U. Над NY-VM01 и NY-VM02 располагались кабели, занимающие 1U стоечного пространства, а также находился один из гигабитных FEX. К счастью для нас, оба 10-гигабитных FEX уже были подключены, поэтому можно было вынуть старый коммутатор чуть раньше. Это означало, что новая виртуальная структура могла начать работать с опережением графика. Да, мы уже идем не по плану. Так обычно и происходит. Вы спрашиваете, чем мы заменим старые виртуальные серверы? Хороший вопрос! Вот этими негодяями:
Это два шасси Dell PowerEdge FX2, с двумя блейд-серверами FC630 каждый. Блейд-сервер имеет два 18-ядерных процессора Intel E5-2698v3 и 768 Гбайт оперативной памяти (это только половина общей доступной емкости). Каждый аппаратный блок обладает uplink-портами со скоростью передачи 80 Гбит/с и четырьмя двухканальными 10-гигабитными модулями ввода/вывода. Вот так они выглядят на стойке:
Разделение серверов между двумя корзинами позволило выиграть дополнительное пространство для расширения в будущем и избежать наличия единой точки отказа для виртуальных хостов. Это было несложно, правда? Хотя мы не планировали заниматься сетью в этот день, оказалось, что агрегаторы ввода/вывода, по своей сути, являются полными коммутаторами с четырьмя внешними и восемью внутренними портами на 10 Гбит/с (по два на блейд-сервер). Когда мы разобрались в том, что они могут делать, а что не могут, то поставили все на свои места и подключили – новые хосты ушли в работу.
Важно отметить, что никто из парней в дата-центре не занимался архитектурой виртуальных машин, когда сеть ожила. Мы сделали так, чтобы Шейн Мадден смог настроить все удаленно. Когда новые NY-VM01 и NY-VM02 (блейд-серверы) вышли в сеть, мы мигрировали все виртуальные машины на эти два хоста и получили возможность демонтировать старые серверы NY-VM03-05, чтобы освободить побольше места. После этого Шейн запустил два последних блейд-сервера, и вот наш зверь уже рвется в бой! В итоге: мы получили процессоры значительно большей мощности, большее количество памяти (объем увеличился с 512 Гбайт до 3078 Гбайт) и модернизировали сетевую составляющую. Старые хосты имели четыре гигабитных канала связи для всех подключений и два 10-гигабитных канала для доступа к СХД с помощью протокола iSCSI. Новые блейд-серверы имеют 20-гигабитные trunk-порты связи со всеми сетями.
Но мы еще не закончили. Это новый блок СХД EqualLogic PS6210 (внизу виднеется NY-LOGSQL01):
Нашей старой СХД был блок PS6200 с двадцатью четырьмя 10k HDD на 900 Гбайт и трансиверами SFP+. Более новая версия поддерживает стандарт 10GBASE-T и содержит двадцать четыре 10k HDD на 1,2 Тбайт, то есть работает быстрее, обладает большим дисковым пространством и способностью подключаться/отключаться к/от СХД. Наряду с новой СХД мы установили новый сервер NY-LOGSQL01, заменив устаревший Dell R510, который никогда не задумывался как SQL-сервер – он был куплен под сетевое хранилище.
Место, освобождённое из-под хостов виртуальных машин, дало нам возможность установить новый файловый сервер и сервер поддержки:
Примечание: сервер поддержки NY-UTIL02 имеет несколько слотов под жесткие диски, поэтому мы могли установить 8 дисков Samsung 840 Pro и создать RAID 0, чтобы восстановить и протестировать SQL-бэкапы, которые делались каждую ночь. RAID-массив уровня 0 создан потому, что абсолютно все данные загружаются туда «с нуля» – терять нам нечего. Важный урок мы получили в прошлом году, когда узнали, что 840 Pro не имеют конденсаторов, и отключение энергии при работающих накопителях вызывает потери данных, так как в них используются модули DIMM для записи в кэш. Поэтому мы остановили свой выбор на дисках Intel S3700 800Гбайт, оставшихся после апгрейда SQL-сервера в нашем NY-DEVSQL01, а менее надежные 840 Pro переставили на сервер восстановления, где их недостаток не будет вредить работе.
Ну ладно, давайте вернемся в нашу снежную реальность. К этому моменту престал ходить общественный транспорт, и номера всех отелей в шаговой доступности (из-за метели) были распроданы. Хотя мы начали искать апартаменты, как только прибыли на место работ, удача нам не улыбнулась. Буря оказалась гораздо слабее, чем предполагалось, но вырубить электричество она все же смогла. Нами было принято решение продолжить работу, насколько это возможно, чтобы опередить график – это было решение парней на месте, не руководства. Сотрудники Stack Exchange знают свое дело. Мы любим свою работу.
Если жизнь протягивает вам лимон… то «забейте» на глупый лимон и собирайте новое блестящее оборудование!
И все же нам пришлось попросить помощи у QTS. Эти ребята отрядили менеджера, чтобы он нашел нам хоть какое-нибудь место для ночлега и пару кроватей, на которые можно было бы рухнуть. Этот парень даже заказал нам пиццу и напитки, чтобы мы не умерли с голоду – об этом мы его не просили. Сервис QTS всегда потрясающий, и если вам срочно нужен хостинг, то рекомендуем воспользоваться их услугами.
Когда все виртуальные машины заработали, СХД была настроена, а несколько проводов были выдраны, часы показывали 9:30 утра вторника – в это время начинает ходить электричка. Чтобы подвести итоги долгой ночи скажу, что нас чуть не хватил инфаркт, когда машина выдала вот это:
Оказалось, что блок питания был ну слишком ужасным и требовал замены. BIOS успешно обновился после удаления неисправного блока питания, а замена для него пришла еще до окончания недели. Отметим: мы заказали новый блок питания, вместо того, чтобы заниматься ремонтом старого (это мы сделали потом). В дата-центре мы храним запасные блоки питания всех используемых уровней мощности, количество которых мы всегда пытаемся свести к минимуму.
День 2 (Вторник, 27 января): Мы немного поспали, немного поели и прибыли на место около 8 вечера. Второй день начался со сборки веб-серверов:
Инициировав перестроение трех серверов под новое оборудование, мы провели апгрейд R620, поменяв четыре гигабитных дочерних платы на две 10-гигабитные и две гигабитные. Вот так выглядит сервер NY-SERVICE03:
Перестройка веб-серверов дала нам шанс привести кабели в порядок. Помните те два SFP+ FEX? К ним почти ничего не подключено:
Остались подключенными только старая СХД и старое сетевое хранилище для SQL R510. Здесь мы столкнулись с первыми трудностями. Мы планировали установить третью PCIe-карту на сервер бэкапа, представленный на картинке:
Мы знали, что десятислотовый аппаратный блок Dell R620 имеет 3 укороченные PCIe-карты. Также мы знали, что у него есть SAS-контроллер для DAS и PCIe-карта для 10-гигабитных соединений SFP+ (он располагался в сетевой стойке с ядром сети, в которой все 96 портов – SFP+ 10 Гбит). Все встало из-за ленточного накопителя, которому требовался еще один SAS-контроллер, о котором мы забыли. Черт. Ладно, так бывает. Новый план.
У нас были дополнительные 10-гигабитные сетевые дочерние карты (NDC), поэтому мы решили заменить NDC у бэкап-сервера, удалив адаптер PCIe SFP+ и заменив его новым 12-гигабитным SAS-контроллером. Мы забыли принести монтажный кронштейн для новых карт, поэтому пришлось импровизировать и самостоятельно изготавливать замену из кусков металла (позже выяснилось, что все карты поставляются без кронштейнов – теперь затея с работой по металлу выглядит менее глупой). Как мы могли подключить карту 10GBASE-T к ядру сети? Никак. По крайней мере, не 10 Гбит. Последние два блока SFP+ в стойке С также нужно было куда-то деть, поэтому было решено поменять их местами с бэкап-сервером (включая новую DAS MD1400). Ему понравился новый дом:
Наконец мы могли полностью отключить оставшиеся SFP+ FEX, запустить KVM и привести дела на стойке С в порядок:
Видите? Ради этого все и затевалось. Последним элементом, который занял свое место на стойке С, был NY-GIT02 – наш новый сервер Gitlab и TeamCity:
Примечание: раньше TeamCity работал под управлением Windows на NY-WEB11, но Джефф Дэлгас подкинул идею – в ходе апгрейда перевести его на NY-GIT02. Поскольку эти зависимости связаны (для обеих создается off-site бэкап), такое объединение имело смысл. Это ускорило доступ TeamCity к диску (он проводит множество операций с XML-файлами) и сделало веб-составляющую более однородной. Теперь «падение» сервера NY-WEB11 (что было неизбежно) будет гораздо менее разрушительным. Дэлгас все сделал сам, работая удаленно из Орегона. Пока Дэлгас занимался своим делом, Грэг боролся с установкой DSC, которая висла из-за git на наших веб-серверах:
Ничего себе, так много красного! А это Грэг, сидящий с моим ноутбуком. Привет Грэг! Поскольку сборка веб-серверов – относительно новая для нас задача, мы решили потратить немного времени и привести кабели в порядок. KVM устанавливались второпях – кабели все равно бы пришлось разводить повторно. В стойке А, например, мы переместили 10-гигабитный FEX выше на 1U, чтобы расширить место для кабелей до 2U и добавить 1U между KVM’ами. Вот что получилось (в начале и в конце):
Поскольку нам пришлось заново тянуть кабели от гигабитных FEX, расположенных посередине стоек A и B (все 4 были удалены), к 10-гигабитному FEX верхнего уровня, то было принято решение поменять местами несколько блоков. Распределители нагрузки CloudFlare, расположенные прямо под веб-серверами, переместились выше на свободное место, образовавшееся после виртуализации DNS серверов, где они присоединились к двум другим общим распределителям. Удаление гигабитного FEX из 10-гигабитной архитектуры освободило в середине стоек A и B еще больше места. Вот фотографии до и после:
После завершения работы над двумя веб-серверами, укладки кабелей и удаления сетевой аппаратуры, часы показывали 8:30 утра, и мы закончили, чтобы урвать немного сна. Все шло хорошо – нам оставалось только доделать половину нашего веб-слоя, развести кабели и заменить еще пару серверов.
День 3 (Среда, 28 января): Мы вернулись в дата-центр около 5 часов вечера – во всеоружии и готовые работать. Последними менялись серверы Redis и «сервис-серверы» (сервер для реализации tag engine, сервер индексирования ElasticSearch и другие):
У нас были три бокса с серверами для реализации tag engine (исключительно для перезагрузки после зависания и достижения оптимального уровня параллелизма – они никогда не загружались полностью) и два сервера Redis в дата-центре в Нью-Йорке. Одним из боксов, предназначенных для tag engine, был уже известный R620, получивший обновление до 10 Гбит чуть ранее, поэтому сейчас мы его не трогали. Остались NY-SERVICE04, NY-SERVICE05, NY-REDIS01 и NY-REDIS02. Весь процесс замены предельно прост, хотя мы выяснили кое-что интересное: если вы переставите оба диска с ОС из массива RAID10, расположенного в R610, в новый R630, то Windows 2012 загрузится как надо, без проблем. Это на мгновение поставило нас в тупик, потому что мы не помнили, чтобы поднимали массив за последние 3 минуты. Процесс перестроения массива весьма прост: развернуть из нашего образа Windows 2012 R2, установить обновления и DSC, а затем специализированное ПО через скрипты. StackServer (с точки зрения сисадмина) – это просто оконный сервис, а билд TeamCity управляет установкой – для этого есть специальный флаг. Эти боксы также имеют небольшие экземпляры IIS для внутренних сервисов, которые являются простой надстройкой. Последней их задачей является организация общего доступа к DFS хранилищу, которое мы хотели сократить, чтобы упростить топологию. Мы оставили этот вопрос и занялись им на следующей неделе – у нас был NY-SERVICE03 для управления общим файловым хранилищем и данную работу можно было сделать удаленно. Для Redis всегда создается слэйв-цепочка, которая выглядит вот так:
Это означает, что мы можем апгрейдить сервер, откатывать обновления и апгрейдить его снова, не прерывая работу сервиса. Вот фотография новых суперских веб-серверов после всех выполненных работ:
Старое решение для веб-серверов Dell R610 с двумя процессорами Intel E5640 и 48 Гбайт оперативной памяти (обновлявшееся с течением времени) сменилось новым, имеющим два процессора Intel 2678W v3 и 64 Гбайт памяти DDR4. Мы использовали те же два Intel 320 SSD объемом 300 Гбайт для RAID 1 с операционной системой на борту. Если вам интересна спецификация всего оборудования, в следующем посте мы сделаем подробный отчет о нашей текущей инфраструктуре.
День 4 (Четверг, 29 января): Я сражался со стойкой D. Большая часть дня была потрачена на работу со стойкой, поскольку теперь были подключены почти все необходимые кабели – просто не все нужные детали пришли вовремя. Нам не хватило нескольких сетевых и силовых кабелей, как вы можете заметить на фото, но мы закончили 98% работы.
Потребовалось время, чтобы привести стойку в порядок. Нам пришлось добавить рукава для кабелей (где их не хватало) и скрупулёзно заменить большую часть проводов. Как понять, что кабель воткнут в нужный порт? Как узнать, куда идет его другой конец? Метки. Много-много меток. Мы пометили оба конца всех кабелей. На это ушло много времени, но это позволит сэкономить его в будущем.
Вот так выглядят стойки теперь, когда мы закончили:
Они не идеальны, поскольку у нас не хватило пары кабелей нужного цвета и длины. Мы заказали их, и Джордж доведет дело до конца.
Я знаю, что вы думаете. Мы тоже считаем, что он не так прекрасен, как хотелось бы.
Весь фотоотчет
Стрим #SnowOps в Twitter
Что пошло не так
Ниже представлен график среднего времени обработки страницы. Если присмотритесь, то увидите, в какой момент был проведен апгрейд:
Уменьшение времени обработки страницы (приблизительно с 30-35 до 10-15 мс) – это лишь маленькая верхушка айсберга. Следующий пост в этой серии будет посвящен детальному обзору других улучшений, к которым привел апгрейд.
Ответы на вопросы читателей оригинального поста на английском можно прочитать по этой ссылке.
Несколько недель назад мы обновили базовую инфраструктуру нашего дата-центра в Нью-Йорке (ладно, теперь он в Нью-Джерси, но это пока секрет). Мы не любим ничего скрывать (включая инфраструктуру) и считаем открытость важнейшим благом нашей работы. Вот история о том, как мы модернизировали наш дата-центр. Для начала взгляните, с чего начинался Stack Overflow – фотографии сделаны 5 лет назад, а с того момента в сфере аппаратного обеспечения многое изменилось.
Зачем?
Мы не меняли ни единого сервера со времен апгрейда начальной конфигурации веб-серверов – в этом просто не было нужды с тех пор, как мы переместили наш дата-центр в Нью-Йорк (это случилось 23 октября 2010 года – больше 4 лет назад). Мы всегда реорганизуем, настраиваем и проверяем наше оборудование, а также оптимизируем код и инфраструктуру, когда это возможно. Чаще всего мы делаем это с целью увеличить скорость загрузки страниц – снижение нагрузки на ЦПУ и снижение объёма занимаемой памяти веб-сервера чаще проявляются как побочный (но чрезвычайно полезный) эффект.
Что случилось? Мы провели встречу. В октябре прошлого года все инженеры Stack Exchange собрались вместе в штаб-квартире в Денвере и приняли серию решений. На той встрече мы ограничили жизненный цикл аппаратной части, посчитав это выгодным с экономической точки зрения. Тогда было установлено, что аппаратное обеспечение должно эксплуатироваться примерно 4 года. По истечении этого времени оно списывается, заменяется или эксплуатируется еще какое-то время – такой подход позволяет упростить планирование. Например, мы ограничили себя двумя поколениями серверов, после которых мы не продлеваем на них гарантию (разве что, только в исключительных ситуациях), и теперь мы можем заказывать «железо» заранее, сразу оформляя четырехлетнюю гарантию.
Почему 4 года? Цифра взята с потолка? Что ж, так и есть. В тот момент у нас работало оборудование четырехлетней давности и вполне справлялось со своими задачами. Вот и все, зачем что-то выдумывать? Большинство компаний списывают аппаратное обеспечение через три года, упрощая ответ на вопрос: «Что нам с ним делать?». Списанное оборудование означает, что оно снято с учета, и мы можем направить его на другие цели, продать или просто отдать сотрудникам на растерзание. Знаете, не так давно нам удалось привлечь немного денег. Хоть конечные суммы не были озвучены на встрече в Денвере, мы знали, что в 2015 году будет производиться замена оборудования.
За два месяца мы подсчитали количество оборудования старше 4 лет (или приближающегося к этой цифре по возрасту). Оказалось, что все 11-е поколение нашего оборудования марки Dell (включая решения для веб-уровня) подошло под этот критерий – потому было принято решение заменить все поколение, решив массу управленческих проблем одним махом. Управление только 12-м и 13-м поколениями программного и аппаратного обеспечения упрощает жизнь в целом. К тому же, обновление программного обеспечения позволяет поднять уровень производительности 12-го поколения до 13-го (конца апреля 2015 года).
Что попало «под раздачу»
За эти два месяца мы поняли, что используем очень много старых серверов (большинство из них функционируют с мая 2010 года):
- Веб-серверы (11 машин)
- Серверы Redis (2 машины)
- Второй SQL-кластер (3 машины, 1 из которых находится в Орегоне)
- Файловый сервер
- Сервер поддержки
- Серверы виртуальных машин (5 машин)
- Серверы для реализации tag engine (2 машины)
- База данных для хранения SQL логов
У нас имелось дополнительное место, чтобы разместить новые серверы, поэтому добавим в список:
- Дополнительную СХД (SAN)
- Дополнительную систему DAS для сервера бэкапов
Получилось довольно много серверов под замену. Как много? Вот столько:
Апгрейд
Я знаю, что вы думаете: «Ник, как вы начали модернизировать такую разнородную гору серверов?» Я рад, что вы спросили. Вот вам история модернизации инфраструктуры Stack Exchange в оперативном дата-центре. Мы решили не использовать функцию аварийного переключения для проведения апгрейда, вместо этого мы использовали множество резервных блоков, через которые временно шел трафик.
День -3 (Вторник, 22 января): Наш план апгрейда был готов (на это ушло порядка полутора дней) и учитывал все аспекты, которые нам пришло в голову обсудить. Мы были ограничены по времени непосредственных работ в дата-центре, поэтому расписали и продумали все заранее (большинство пунктов прошло по плану). Полный план вы можете найти здесь.
День 0 (Воскресенье, 25 января): Сисадминами, которые непосредственно занимались апгрейдом, были Джордж Бич (George Beech), Грэг Брей (Greg Bray) и Ник Крэйвер (Nick Craver) (следует отметить, что несколько системных администраторов выполняли свою работу удаленно, и их вклад в работу был не меньшим: Джефф Дэлгас (Geoff Dalgas) работал из Карвелиса, Шейн Мадден (Shane Madden) – из Денвера, а Том Лимончелли (Tom Limoncelli), который очень помог с планированием, – из Нью-Джерси). Сразу после начала работ мы получили предупреждение о снегопаде, поэтому перед отъездом в Нью-Йорк упаковали теплые вещи.
День 1 (Понедельник, 26 января): Хотя наш офис находится в нижней части Манхеттена, дата-центр располагается на другой стороне реки Гудзон в Джерси-Сити:
Мы знали, что нас ждет гора работы. Проблема была в том, что если мы поедем в понедельник, то, вероятно, не сможем вернуться в дата-центр во вторник, так как линию метро до Нью-Джерси закроют. Так и произошло. Но команда решила начинать работу. Мы прихватили с собой все, что нужно, чтобы заночевать на месте, и направились в дата-центр. Вот что ждало нас там, в ожидании установки:
Да, мы были взволнованы! Перед тем, как начать апгрейд, нам нужно было решить важную задачу с серверами Redis, занятыми объявлениями Targeted Job. Эти машины изначально управлялась Cassandra (мы отключили это хранилище), а затем Elasticsearch (и его тоже отключили), теперь они работали под управлением Redis. Как мы ими распорядились? Джейсон Паньон (Jason Punyon) и Кевин Монро (Kevin Montrose) ведут интересный блог о нашем проекте Providence. Вы можете найти пост Паньона, в котором он рассказывает, что произошло с каждым из этих хранилищ.
Для этих систем были заказаны жесткие диски Samsung 840 Pro, которые, как выяснилось, имеют серьёзный баг в прошивке. Из-за этого бага копирование с сервера на сервер в дублированной 10-гигабитной сети производилось на скорости 12 МБ/сек (ух!). Если учесть, что в экземплярах Redis хранятся сотни гигабайт, то можно сказать, что для нас это было неприемлемо. Нам нужно было обновить прошивку дисков, чтобы восстановить работоспособность и перестроить массивы RAID10. Поскольку через большую часть USB-интерфейсов обновить прошивку нельзя, мы разобрали на части бедную машину, чтобы осуществить задуманное:
Когда процесс был запущен, он шел в фоновом режиме, параллельно с другой работой (поскольку для перестроения массива RAID10 с данными на борту требуется несколько десятков минут, даже если используется диск SSD). В результате удалось увеличить скорость копирования файлов до 100-200 Мбайт/сек (мы вскоре столкнемся с еще одной проблемой – нужно еще многое настроить). Теперь начинается самое интересное. В серверной стойке С (мы очень уважительно относимся к нашим стеллажам и даем им буквенные имена) мы хотели заменить подключение SFP+ 10 Гбит с шириной внешнего канала 1 Гбит на интерфейс 10GBASE-T (разъем RJ45). Это делалось по нескольким причинам: кабель, используемый для SFP+, называется твинаксиальным: его очень сложно прокладывать и непросто напрямую подключить к дочерним картам серверов Dell. Также, SFP+ FEX не позволяют подключать устройства стандарта 10GBASE-T, которые могут появиться позднее (именно в этой стойке их нет, но они могут быть в других, например, в распределителе нагрузки). Вот, что было установлено в стойке С:
- Наверху стойки – два Nexus 2232PP 10Гбит SFP+ FEX
- Посередине – два Nexus 2248TP-E 1Гбит BASE-T FEX
- Один управляемый коммутатор 2960
- Два KVM-переключателя компании Avocent
- Кабель-организатор Panduit, 6U
Мы хотели прийти к этому:
- Два Nexus 2232PP 10Гбит SFP+ FEX
- Один управляемый коммутатор 2960
- Один KVM-переключатель компании Avocent
- Кабель-организатор Panduit, 5U
В планах было упростить конфигурацию сети, уменьшить количество кабелей и количество элементов в целом, при этом сэкономив 4U свободного пространства. Вот так выглядела верхняя часть стойки, когда мы начали:
…а это её средняя часть (уже без кабель-организатора):
Самое время начинать. Во-первых, нам нужно было, чтобы KVM продолжали работать, поэтому мы их… «временно переместили»:
Теперь, когда нам ничего не мешает, самое время спустить SFP+ FEX вниз, чтобы мы могли установить новые 10GBASE-T FEX на свое место:
Принцип работы технологии FEX позволяет нам выделить от 1 до 8 uplink портов для каждого коммутатора. Это означает, что мы можем отключить четыре порта от каждого FEX, не прерывая работу сети, затем взять четыре из них, отключенные от VPC, и переназначить на новое устройство. В ходе апгрейда схема подключения будет изменяться следующим образом: 8/0 -> 4/4 -> 0/8. Фотография в середине данного процесса:
Новая сеть готова – можно начинать установку серверов: несколько старых мы выдернули, так как один был виртуализирован, а два других уже были не нужны. Дополнительно были ликвидированы хосты NY-VM01 и NY-VM02, что позволило освободить место на стойке в размере 5U. Над NY-VM01 и NY-VM02 располагались кабели, занимающие 1U стоечного пространства, а также находился один из гигабитных FEX. К счастью для нас, оба 10-гигабитных FEX уже были подключены, поэтому можно было вынуть старый коммутатор чуть раньше. Это означало, что новая виртуальная структура могла начать работать с опережением графика. Да, мы уже идем не по плану. Так обычно и происходит. Вы спрашиваете, чем мы заменим старые виртуальные серверы? Хороший вопрос! Вот этими негодяями:
Это два шасси Dell PowerEdge FX2, с двумя блейд-серверами FC630 каждый. Блейд-сервер имеет два 18-ядерных процессора Intel E5-2698v3 и 768 Гбайт оперативной памяти (это только половина общей доступной емкости). Каждый аппаратный блок обладает uplink-портами со скоростью передачи 80 Гбит/с и четырьмя двухканальными 10-гигабитными модулями ввода/вывода. Вот так они выглядят на стойке:
Разделение серверов между двумя корзинами позволило выиграть дополнительное пространство для расширения в будущем и избежать наличия единой точки отказа для виртуальных хостов. Это было несложно, правда? Хотя мы не планировали заниматься сетью в этот день, оказалось, что агрегаторы ввода/вывода, по своей сути, являются полными коммутаторами с четырьмя внешними и восемью внутренними портами на 10 Гбит/с (по два на блейд-сервер). Когда мы разобрались в том, что они могут делать, а что не могут, то поставили все на свои места и подключили – новые хосты ушли в работу.
Важно отметить, что никто из парней в дата-центре не занимался архитектурой виртуальных машин, когда сеть ожила. Мы сделали так, чтобы Шейн Мадден смог настроить все удаленно. Когда новые NY-VM01 и NY-VM02 (блейд-серверы) вышли в сеть, мы мигрировали все виртуальные машины на эти два хоста и получили возможность демонтировать старые серверы NY-VM03-05, чтобы освободить побольше места. После этого Шейн запустил два последних блейд-сервера, и вот наш зверь уже рвется в бой! В итоге: мы получили процессоры значительно большей мощности, большее количество памяти (объем увеличился с 512 Гбайт до 3078 Гбайт) и модернизировали сетевую составляющую. Старые хосты имели четыре гигабитных канала связи для всех подключений и два 10-гигабитных канала для доступа к СХД с помощью протокола iSCSI. Новые блейд-серверы имеют 20-гигабитные trunk-порты связи со всеми сетями.
Но мы еще не закончили. Это новый блок СХД EqualLogic PS6210 (внизу виднеется NY-LOGSQL01):
Нашей старой СХД был блок PS6200 с двадцатью четырьмя 10k HDD на 900 Гбайт и трансиверами SFP+. Более новая версия поддерживает стандарт 10GBASE-T и содержит двадцать четыре 10k HDD на 1,2 Тбайт, то есть работает быстрее, обладает большим дисковым пространством и способностью подключаться/отключаться к/от СХД. Наряду с новой СХД мы установили новый сервер NY-LOGSQL01, заменив устаревший Dell R510, который никогда не задумывался как SQL-сервер – он был куплен под сетевое хранилище.
Место, освобождённое из-под хостов виртуальных машин, дало нам возможность установить новый файловый сервер и сервер поддержки:
Примечание: сервер поддержки NY-UTIL02 имеет несколько слотов под жесткие диски, поэтому мы могли установить 8 дисков Samsung 840 Pro и создать RAID 0, чтобы восстановить и протестировать SQL-бэкапы, которые делались каждую ночь. RAID-массив уровня 0 создан потому, что абсолютно все данные загружаются туда «с нуля» – терять нам нечего. Важный урок мы получили в прошлом году, когда узнали, что 840 Pro не имеют конденсаторов, и отключение энергии при работающих накопителях вызывает потери данных, так как в них используются модули DIMM для записи в кэш. Поэтому мы остановили свой выбор на дисках Intel S3700 800Гбайт, оставшихся после апгрейда SQL-сервера в нашем NY-DEVSQL01, а менее надежные 840 Pro переставили на сервер восстановления, где их недостаток не будет вредить работе.
Ну ладно, давайте вернемся в нашу снежную реальность. К этому моменту престал ходить общественный транспорт, и номера всех отелей в шаговой доступности (из-за метели) были распроданы. Хотя мы начали искать апартаменты, как только прибыли на место работ, удача нам не улыбнулась. Буря оказалась гораздо слабее, чем предполагалось, но вырубить электричество она все же смогла. Нами было принято решение продолжить работу, насколько это возможно, чтобы опередить график – это было решение парней на месте, не руководства. Сотрудники Stack Exchange знают свое дело. Мы любим свою работу.
Если жизнь протягивает вам лимон… то «забейте» на глупый лимон и собирайте новое блестящее оборудование!
И все же нам пришлось попросить помощи у QTS. Эти ребята отрядили менеджера, чтобы он нашел нам хоть какое-нибудь место для ночлега и пару кроватей, на которые можно было бы рухнуть. Этот парень даже заказал нам пиццу и напитки, чтобы мы не умерли с голоду – об этом мы его не просили. Сервис QTS всегда потрясающий, и если вам срочно нужен хостинг, то рекомендуем воспользоваться их услугами.
Когда все виртуальные машины заработали, СХД была настроена, а несколько проводов были выдраны, часы показывали 9:30 утра вторника – в это время начинает ходить электричка. Чтобы подвести итоги долгой ночи скажу, что нас чуть не хватил инфаркт, когда машина выдала вот это:
Оказалось, что блок питания был ну слишком ужасным и требовал замены. BIOS успешно обновился после удаления неисправного блока питания, а замена для него пришла еще до окончания недели. Отметим: мы заказали новый блок питания, вместо того, чтобы заниматься ремонтом старого (это мы сделали потом). В дата-центре мы храним запасные блоки питания всех используемых уровней мощности, количество которых мы всегда пытаемся свести к минимуму.
День 2 (Вторник, 27 января): Мы немного поспали, немного поели и прибыли на место около 8 вечера. Второй день начался со сборки веб-серверов:
Инициировав перестроение трех серверов под новое оборудование, мы провели апгрейд R620, поменяв четыре гигабитных дочерних платы на две 10-гигабитные и две гигабитные. Вот так выглядит сервер NY-SERVICE03:
Перестройка веб-серверов дала нам шанс привести кабели в порядок. Помните те два SFP+ FEX? К ним почти ничего не подключено:
Остались подключенными только старая СХД и старое сетевое хранилище для SQL R510. Здесь мы столкнулись с первыми трудностями. Мы планировали установить третью PCIe-карту на сервер бэкапа, представленный на картинке:
Мы знали, что десятислотовый аппаратный блок Dell R620 имеет 3 укороченные PCIe-карты. Также мы знали, что у него есть SAS-контроллер для DAS и PCIe-карта для 10-гигабитных соединений SFP+ (он располагался в сетевой стойке с ядром сети, в которой все 96 портов – SFP+ 10 Гбит). Все встало из-за ленточного накопителя, которому требовался еще один SAS-контроллер, о котором мы забыли. Черт. Ладно, так бывает. Новый план.
У нас были дополнительные 10-гигабитные сетевые дочерние карты (NDC), поэтому мы решили заменить NDC у бэкап-сервера, удалив адаптер PCIe SFP+ и заменив его новым 12-гигабитным SAS-контроллером. Мы забыли принести монтажный кронштейн для новых карт, поэтому пришлось импровизировать и самостоятельно изготавливать замену из кусков металла (позже выяснилось, что все карты поставляются без кронштейнов – теперь затея с работой по металлу выглядит менее глупой). Как мы могли подключить карту 10GBASE-T к ядру сети? Никак. По крайней мере, не 10 Гбит. Последние два блока SFP+ в стойке С также нужно было куда-то деть, поэтому было решено поменять их местами с бэкап-сервером (включая новую DAS MD1400). Ему понравился новый дом:
Наконец мы могли полностью отключить оставшиеся SFP+ FEX, запустить KVM и привести дела на стойке С в порядок:
Видите? Ради этого все и затевалось. Последним элементом, который занял свое место на стойке С, был NY-GIT02 – наш новый сервер Gitlab и TeamCity:
Примечание: раньше TeamCity работал под управлением Windows на NY-WEB11, но Джефф Дэлгас подкинул идею – в ходе апгрейда перевести его на NY-GIT02. Поскольку эти зависимости связаны (для обеих создается off-site бэкап), такое объединение имело смысл. Это ускорило доступ TeamCity к диску (он проводит множество операций с XML-файлами) и сделало веб-составляющую более однородной. Теперь «падение» сервера NY-WEB11 (что было неизбежно) будет гораздо менее разрушительным. Дэлгас все сделал сам, работая удаленно из Орегона. Пока Дэлгас занимался своим делом, Грэг боролся с установкой DSC, которая висла из-за git на наших веб-серверах:
Ничего себе, так много красного! А это Грэг, сидящий с моим ноутбуком. Привет Грэг! Поскольку сборка веб-серверов – относительно новая для нас задача, мы решили потратить немного времени и привести кабели в порядок. KVM устанавливались второпях – кабели все равно бы пришлось разводить повторно. В стойке А, например, мы переместили 10-гигабитный FEX выше на 1U, чтобы расширить место для кабелей до 2U и добавить 1U между KVM’ами. Вот что получилось (в начале и в конце):
Поскольку нам пришлось заново тянуть кабели от гигабитных FEX, расположенных посередине стоек A и B (все 4 были удалены), к 10-гигабитному FEX верхнего уровня, то было принято решение поменять местами несколько блоков. Распределители нагрузки CloudFlare, расположенные прямо под веб-серверами, переместились выше на свободное место, образовавшееся после виртуализации DNS серверов, где они присоединились к двум другим общим распределителям. Удаление гигабитного FEX из 10-гигабитной архитектуры освободило в середине стоек A и B еще больше места. Вот фотографии до и после:
После завершения работы над двумя веб-серверами, укладки кабелей и удаления сетевой аппаратуры, часы показывали 8:30 утра, и мы закончили, чтобы урвать немного сна. Все шло хорошо – нам оставалось только доделать половину нашего веб-слоя, развести кабели и заменить еще пару серверов.
День 3 (Среда, 28 января): Мы вернулись в дата-центр около 5 часов вечера – во всеоружии и готовые работать. Последними менялись серверы Redis и «сервис-серверы» (сервер для реализации tag engine, сервер индексирования ElasticSearch и другие):
У нас были три бокса с серверами для реализации tag engine (исключительно для перезагрузки после зависания и достижения оптимального уровня параллелизма – они никогда не загружались полностью) и два сервера Redis в дата-центре в Нью-Йорке. Одним из боксов, предназначенных для tag engine, был уже известный R620, получивший обновление до 10 Гбит чуть ранее, поэтому сейчас мы его не трогали. Остались NY-SERVICE04, NY-SERVICE05, NY-REDIS01 и NY-REDIS02. Весь процесс замены предельно прост, хотя мы выяснили кое-что интересное: если вы переставите оба диска с ОС из массива RAID10, расположенного в R610, в новый R630, то Windows 2012 загрузится как надо, без проблем. Это на мгновение поставило нас в тупик, потому что мы не помнили, чтобы поднимали массив за последние 3 минуты. Процесс перестроения массива весьма прост: развернуть из нашего образа Windows 2012 R2, установить обновления и DSC, а затем специализированное ПО через скрипты. StackServer (с точки зрения сисадмина) – это просто оконный сервис, а билд TeamCity управляет установкой – для этого есть специальный флаг. Эти боксы также имеют небольшие экземпляры IIS для внутренних сервисов, которые являются простой надстройкой. Последней их задачей является организация общего доступа к DFS хранилищу, которое мы хотели сократить, чтобы упростить топологию. Мы оставили этот вопрос и занялись им на следующей неделе – у нас был NY-SERVICE03 для управления общим файловым хранилищем и данную работу можно было сделать удаленно. Для Redis всегда создается слэйв-цепочка, которая выглядит вот так:
Это означает, что мы можем апгрейдить сервер, откатывать обновления и апгрейдить его снова, не прерывая работу сервиса. Вот фотография новых суперских веб-серверов после всех выполненных работ:
Старое решение для веб-серверов Dell R610 с двумя процессорами Intel E5640 и 48 Гбайт оперативной памяти (обновлявшееся с течением времени) сменилось новым, имеющим два процессора Intel 2678W v3 и 64 Гбайт памяти DDR4. Мы использовали те же два Intel 320 SSD объемом 300 Гбайт для RAID 1 с операционной системой на борту. Если вам интересна спецификация всего оборудования, в следующем посте мы сделаем подробный отчет о нашей текущей инфраструктуре.
День 4 (Четверг, 29 января): Я сражался со стойкой D. Большая часть дня была потрачена на работу со стойкой, поскольку теперь были подключены почти все необходимые кабели – просто не все нужные детали пришли вовремя. Нам не хватило нескольких сетевых и силовых кабелей, как вы можете заметить на фото, но мы закончили 98% работы.
Потребовалось время, чтобы привести стойку в порядок. Нам пришлось добавить рукава для кабелей (где их не хватало) и скрупулёзно заменить большую часть проводов. Как понять, что кабель воткнут в нужный порт? Как узнать, куда идет его другой конец? Метки. Много-много меток. Мы пометили оба конца всех кабелей. На это ушло много времени, но это позволит сэкономить его в будущем.
Вот так выглядят стойки теперь, когда мы закончили:
Они не идеальны, поскольку у нас не хватило пары кабелей нужного цвета и длины. Мы заказали их, и Джордж доведет дело до конца.
Я знаю, что вы думаете. Мы тоже считаем, что он не так прекрасен, как хотелось бы.
Весь фотоотчет
Стрим #SnowOps в Twitter
Что пошло не так
- Мы бы соврали, если бы сказали, что все прошло гладко. Апгрейды оборудования таких масштабов не проходят без проблем. Во время планирования выделяйте время с учетом возможных неприятностей.
- Помните, как в 2010 году мы обновили сервера базы данных, а повышение производительности оказалось не таким, каким мы ожидали? Так вот, есть такой баг: система с BIOS версий 1.0.4/1.1.4 просто не учитывает настройки производительности. Сейчас мы помогаем Dell отследить его. В случае с Windows, для поддержания производительности на максимальном уровне помогало отключение C-States (технология энергосбережения процессоров). В случае с CentOS 7 подобного эффекта не наблюдалось – здесь помогало только отключение PState драйвера. Мы даже заказали и собрали небольшой R630, чтобы протестировать и найти неисправность, а также проверить наши навыки в сборке «железа» – довести их до автоматизма. Что бы ни вызывало эту ошибку, наша задача помочь поставщику выпустить патч, чтобы другие не столкнулись с этим гадким сюрпризом.
- Мы столкнулись с проблемой при выполнении скриптов настройки DSC: для завершения настройки сервера уходили в перезагрузку, но после перезагрузки ничего не менялось, что вылилось в циклическую перезагрузку. Также были трудности с установкой клиента git на этих машинах.
- Мы вдруг поняли, что запуск «голого» сервера с IIS – это очень плохая идея. Приносим свои извинения.
- Мы поняли, что если переместить диски из RAID-массива R610 в R630 и не отловить момент появления запроса загрузки через PXE, то сервер беспроблемно загрузит операционную систему.
- Мы определили плюсы и минусы архитектуры Dell FX2 IOA и узнали, что эти блоки являются самодостаточными коммутаторами.
- Мы поняли, что CMC порты на блоке FX2, по своей сути, являются коммутаторами и идеально подходят для «гирляндового» (daisy chaining) соединения устройств. Правда мы сразу же забыли об этом и продублировали подключение, образовав петлю, которая сбросила настройки протокола STP нашей управляющей сети. Упс.
- Оказывается, что чувак из Twitter, который расстраивался по поводу перевёрнутого серверного блока – прав. Проблематично перевернуть открытый вверх ногами веб-сервер, когда из него выкручены несколько важных элементов.
- Мы не упомянули, что это был кабель для зарядки. Фото сильно взбудоражило Twitter. Хотя мы ценим совет про #infosec.
- Мы сильно недооценили любовь Twitter к «голым» серверам. Все в порядке, нам тоже это нравится.
- Мы узнали, что массивы DAS Dell MD1400 (13 поколения и 12Гбит/с) не поддерживают подключение к серверам 12 поколения, например, к нашему бэкап-серверу R620. Мы работаем над решением этой проблемы.
- Мы узнали, что диагностика аппаратного обеспечения Dell не затрагивает блоки питания, даже если на корпусе сервера загорелась оранжевая лампочка, сообщающая о неисправности.
- Мы поняли, что метель – штука холодная, ветер – еще холоднее, а спать полноценные 8 часов в сутки совершенно необязательно.
Выгода
Ниже представлен график среднего времени обработки страницы. Если присмотритесь, то увидите, в какой момент был проведен апгрейд:
Уменьшение времени обработки страницы (приблизительно с 30-35 до 10-15 мс) – это лишь маленькая верхушка айсберга. Следующий пост в этой серии будет посвящен детальному обзору других улучшений, к которым привел апгрейд.
Ответы на вопросы читателей оригинального поста на английском можно прочитать по этой ссылке.
Elektronik
Вот такой и должна быть хорошая техническая статья!
Читал с замиранием сердца. Триллер!