Сервер google: Cloud Computing Services | Google Cloud

Дата-центры Google. Как устроена самая технологичная сеть серверов, разбросанная по всему миру? / Хабр

Серверы в морских контейнерах, туалетная вода для охлаждения, ледяные батареи, почта на магнитной ленте, аллигаторы в пруду и 500 кг выбросов CO2 в секунду.

Google был основан в 1998 году Ларри Пейджем и Сергеем Брином. Последний родился в Москве в семье советских евреев-математиков и выпускников МГУ, впоследствии переехавших в США.

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

На момент 2022 года капитализация «Alphabet Inc», материнской компании Google, составляла порядка 1,5 триллиона долларов. Выручка за 2021 год — чуть больше 257 миллиардов долларов. Над продуктами компании трудится около 163 000 человек по всему миру.

Штаб-квартира Google, именуемая «Googleplex», с самого основания расположена на территории Кремниевой долины в городе Маунтин-Вью штата Калифорния.

Как и подобает огромной технологической компании, основной продукт Google — поисковая система — окружен множеством сервисов и приложений. Наиболее популярные из них: YouTube, Gmail, Google Maps, Google Drive, Google Docs, Google Translate, Google Play.

Кампус «Googleplex» в Калифорнии (Источник: https://studios.com/googleplex.html)

По данным Internet Live Stats за 2017 год, дата-центры Google обрабатывают в среднем 40 миллионов поисковых запросов в секунду, что дает около 3,5 миллиарда запросов в день и 1,2 триллиона — в год.

Поисковая система индексирует около 20 миллиардов веб-страниц каждый день, а сервис показа объявлений AdWords проводит миллионы рекламных аукционов в режиме реального времени. Gmail хранит электронную почту более 500 миллионов пользователей по всему миру, при этом на каждый почтовый ящик в среднем приходится 17 000 писем.

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

Дата-центры в Америке, Европе и Азии

Согласно официальным данным, размещенным на сайте Google, по состоянию на 2022 год компания владеет 14 дата-центрами в Северной Америке, 1 в Южной, 6 в Европе и 2 в Азии. В общей сумме 23 ЦОД, каждый из которых имеет свою историю строительства и уникальные технические особенности. При этом, с 2018 по 2022 год было объявлено о начале возведения еще как минимум 6 дата-центров.

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

Например, регион платформы Google Cloud в Польше был открыт благодаря партнерству с польской компанией DCP (Poland’s Domestic Cloud Provider). Google инвестировал около 2 миллиардов долларов в инфраструктуру ЦОД в Польше, превращая страну в центральную облачную локацию Европы.

Но самый первый сервер компании находился в колокейшн дата-центре Exodus в Санта-Кларе штата Калифорния. Тогда, в 1999 году, у Гугла еще не было своих ЦОД, а имеющаяся мощность — всего 2,5 квадрата инфраструктуры. По соседству стояли серверные стойки eBay, DEC и AltaVista.

В 2003 году, на заре строительства собственных ЦОД, Google разрабатывал модульные дата-центры, которые планировал использовать в будущем. Впоследствии, в 2007 году, технология была запатентована.

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

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

Однако, амбициозные идеи молодой по тем временам компании оказались на пыльной полке опрометчивых идей.

Один из изобретателей, указанный в патенте, Уильям Уиттед, еще в 2007 году публично заявил, что проект портативного центра обработки данных закрыт. Об этом он сообщил в статье San Francisco Chronicle, повествующей о «пенсионерах» компании: «Одна из идей, которую я отстаивал, заключалась в том, чтобы построить переносные центры обработки данных в грузовых контейнерах. Проект, который Google тестировал на стоянке своей штаб-квартиры, в конечном итоге был отменен».

В дальнейшем компания использовала более консервативные, но не менее инновационные в своем исполнении подходы.

Пока инженеры компании тестировали технологию контейнеров, Google в 2003 году построил первый полноценный ЦОД в округе Дуглас города Атланта — столицы штата Джорджия. Избыточная электроэнергия, низкие тарифы на коммунальные услуги (50% от средней по стране), лояльная налоговая система и низкий риск стихийных бедствий делают Дуглас привлекательным местом для размещения дата-центров.

Дата-центр Google в Дугласе

С 2015 года Google, Switch, Microsoft, PWC, Stack, T5 и Digital Realty инвестировали в серверную инфраструктуру Дугласа более 4 млрд долларов. Поэтому в лесистой местности округа возвышается другой крупнейший дата-центр Атланты от компании Switch — The Keep Campus. Его можно наблюдать на спутниковых снимках буквально через дорогу от ЦОД Google.

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

Изначально Google охлаждал оборудование объекта, используя водопроводную воду напрямую, как и в большинстве местных домов. Но в какой-то момент стало понятно, что вода не обязательно должна быть кристально чистой. К тому же, потребление ЦОД настолько велико, что может вызвать нехватку питьевой воды во время засух.

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

По сути, когда жители округа принимают душ или спускают воду в туалетах, они помогают охлаждать ЦОД Google. В планах компании увеличить количество оборотной воды до 100 процентов, исключив использование водопровода округа.

Традиционные ЦОД охлаждают серверные комнаты с помощью гигантских кондиционеров, которые размещаются под фальшполами. Это требует огромного количества энергии. Известно, что дата-центры потребляют до 1,5% всей электроэнергии в мире.

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

Урс Хёльцле (Urs Hölzle) на конференции Google Cloud в Лондоне 2018 года

Подход, используемый в Google, делит серверное пространство на две части: холодная и горячая.

«Холодный коридор» — основное пространство перед серверными стойками, где поддерживается более высокая температура в 26 градусов Цельсия.  

 «Горячий коридор» — узкое пространство между задними панелями двух рядов серверов, плотно закрытое металлическими листами на концах. Температура здесь достигает 50 градусов Цельсия.

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

Медные змеевики в горячем коридоре

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

Такая конструкция, известная как «Close-Coupled Cooling», является системой охлаждения последнего поколения. За счет близкого расположения кондиционера к стойке с оборудованием обеспечивается более точное перемещение приточного и отработанного воздуха.

Этот подход более эффективен, чем потолочная камера для перемещения горячего отработанного воздуха на большие расстояния в кондиционеры машинного зала, именуемая «Computer Room Air Condition» (CRAC).

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

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

Дата-центр Google на берегу реки Колумбия в Далласе

Второй дата-центр Google был построен в 2006 году в городе Даллас штата Орегон. Здесь, на берегу реки Колумбия, в 1950-е годы располагался алюминиевый завод, который закрылся к концу 1980-х.

Как и все последующие ЦОД компании, дата-центр в Орегоне имеет похожую организацию серверных стоек, подвода энергопитания, оборудования для охлаждения и горячих/холодных коридоров.

За все время в дата-центр Далласа было инвестировано 1,8 миллиарда долларов. Первоначальная площадь здания составляла 164 000 квадратных футов. Однако размер последующих расширений держался в тайне.

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

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

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

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

В 2007 году было закончено строительство дата-центра в округе Беркли штата Южная Каролина. С 2013 года объект несколько раз расширялся, достигнув общего объема инвестиций в 2,4 миллиарда долларов. Сегодня здесь работает около 400 человек.

Увидеть масштаб вложений в подобные ЦОД можно со снимков Google Maps — территория объекта действительно впечатляет. Он похож на небольшой микрорайон со своими улицами, дорогами и парковочными местами.

Вид со спутника на дата-центр Google в Южной Каролине

Дата-центр в Южной Каролине один из самый дорогих и нестандартных ЦОД компании. Чтобы уменьшить нагрузку на водоснабжение округа Google собирает дождевую воду в небольшой пруд и использует ее в системе охлаждения.

Для очищения водоема от цветущих водорослей компания экспериментировала с «телапией» — пресноводной рыбой, питающейся водными растениями. Она также является популярным пунктом меню в ресторанах.

По слухам, некогда в пруду обитал 4-футовый аллигатор, однако как обстоят дела сейчас — неизвестно.

Пруд, аккумулирующий дождевую воду

В 2017 году Google опубликовал документ, описывающий преимущества добычи грунтовых вод в округе Беркли для охлаждения своих серверов. На запрос об откачке 1,5 миллионов галлонов в день или 550 миллионов в год законодательный орган ответил крайне жесткими условиями.

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

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

Гидроаккумулирующая электростанция Таум Саук в штате Миссури. Примерно так выглядят 600 миллионов галлонов воды. Столько же потребляют некоторые ЦОД Google за год. Для сравнения — в нижнем правом углу расположены ангар, трейлеры и автомобили. (Источник: Guizhou Quianyuan Power Co. Ltd)

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

А вот где Google может использовать воду свободно, так это в Хамине, Финляндия. В феврале 2009 года Google заплатил 52 миллиона долларов за заброшенную бумажную фабрику на берегу Финского залива, после того, как решил, что 56-летнее здание — идеальное место для строительства массивного вычислительного центра.

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

С 2009 года Google инвестировал 1,2 миллиарда евро в дата-центр в Хамине и его периферийную сетевую инфраструктуру. К моменту завершения первого этапа строительства в 2011 году, более 2000 человек и около 50 финских компаний из различных отраслей приложили руку к проектированию этого ЦОД.

Здесь, как и в Бельгийском дата-центре, Google не использует чиллеры вообще — тут их просто нет. Для отвода тепла от серверов используется система перекачки морской воды.

Охлаждающие установки, качающие морскую воду из Финского залива

Как и в остальных ЦОД компании, воздух из горячего коридора позади серверных стоек передает свое тепло воде.

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

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

Серверные стойки, а между ними «горячие коридоры»

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

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

Дата-центр в городе Сен-Гилен муниципалитета Валлония в Бельгии

Объект, полностью введенный в эксплуатацию в 2010 году, стал первым дата-центром Google в мире, где полностью отсутствует механическое охлаждение в виде чиллеров. Общая сумма инвестиций 1,6 миллиарда евро.

Эти усилия не остались незамеченными, и в 2018 году Европейская комиссия признала дата-центр в Сен-Гилен лучшим за последние десять лет в номинации «Кодекс поведения в области энергоэффективности в центрах обработки данных».

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

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

Установленные рядом с дата-центром 10 665 фотоэлектрических панелей генерирует 2,8 гигаватт-час чистой электроэнергии, питая водоочистную установку предприятия круглый год.

В 2022 году Google модернизировала свой дата-центр в Бельгии, заменив дизельные генераторы на модульные батареи Gridstack от компании Fluence. Аккумуляторы имеют общую энергетическую емкость 5,5 МВтч. Это еще один уверенный шаг в сторону зеленой энергетики.

Резервные источники питания используются во время перебоев в электросети, обеспечивая работоспособность серверов 24 часа в сутки.

Контроль батарей осуществляется программным обеспечением FlexPond от компании Centrica. Система также допускает возможность поставки энергии в электросеть города для обеспечения ее стабильности.

Батареи резервного питания Fluence Gridstack 6-го поколения в дата-центре Google в Бельгии

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

А вот один из азиатских дата-центров в Тайване, расположенный на берегу округа Уезд Чанхуа, со всех сторон окружен 100-метровыми ветряными турбинами.

ЦОД Google в Тайване

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

Похожая система накопления энергии в виде холода используется в дата-центре Phoenix ONE от компании Iron Mountain. Ночью чиллеры охлаждают резервуар с ледяными шариками из криогеля, а днем шарики отводят тепло от воды, циркулирующей через дата-центр.

Помимо термальных батарей, Google совместно с тайваньской энергетической компанией New Green Power создает проект из 40 000 солнечных панелей, расположенных в 100 км от дата-центра.

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

Дата-центр в Сингапуре прямо посреди улицы

Территория комплекса в городе Джуронг-Уэст всего 3 гектара земли. Из-за этого градирни размещены на крыше, а их резервуары — на предпоследнем этаже.

Дешевые серверы, магнитные ленты и армия охранников

Официальных данных о том, сколько серверов находится в распоряжении Google нет. По предположениям Gartner, компании технологических исследований, на момент 2016 года Google владела 2,5 миллионами серверов. Скорее всего, это число стремительно увеличивается по мере расширения серверной инфраструктуры компании.

Однако, точно известно, что еще в самом начале Google отказался от типовых решений, имеющихся на рынке, и разработал собственную серверную платформу.

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

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

Серверные стойки в дата-центре Нидерландов

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

Поскольку стойки Google уже охлаждаются змеевиками, в корпус каждого сервера устанавливается небольшая батарея — каждая соответствуют уровню Gold стандарта Energy Star с КПД не менее 90%. Такая схема снижает потери электроэнергии примерно на 15%.

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

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

В 1999 Урс Хёльцле купил детали для сборки 2000 рабочих прототипов серверов у небольшого поставщика электроники. Исключив ненужные компоненты, Google построил партию серверов примерно по 1500 долларов за штуку вместо стандартных на те времена 5000 долларов.

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

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

С 2016 года Google использует собственные аппаратные акселераторы для приложений машинного обучения. Специальная плата, именуемая «Tensor Processing Unit» (TPU), устанавливается в слот для жесткого диска на сервере и обеспечивают более высокую производительность на ватт для машинного обучения.

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

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

Файловая система является кластерной, несовместима с POSIX и тесно интегрирована с другим продуктом Google — MapReduce. GFS распараллеливает операции на несколько машин одновременно, шифруя и сохраняя информацию минимум в 3 местах одновременно.

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

С 2018 года системы охлаждения в дата-центрах Google полностью управляются искусственным интеллектом, разработанным совместно с DeepMind — лондонской компанией, которую Google приобрел в 2014 году.

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

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

Как сообщает Google, компания снизила энергопотребление периферических систем, не связанных с вычислением (охлаждение, трансформаторы, освещение) до 11%, в отличие от большинства ЦОД, где это значение достигает 50% от общих энергозатрат — то есть около половины.

Поэтому, за счет множества оптимизаций, дата-центры Google имеют беспрецедентный показатель энергоэффективности PUE— 1,10. Для сравнения, согласно опросу среди серверных компаний, проведенному Uptime Institute в 2021 году, средний мировой показатель крупнейших ЦОД составляет около 1,57.

Показатель PUE, первоначально разработанный в 2006 компанией The Green Grid, был опубликован в 2016 году как глобальный стандарт в соответствии с ISO/IEC 30134-2:2016.

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

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

Если бы Google использовал стандартную для отрасли интерпретацию стандарта, каким его задала The Green Grid, дата-центры могли бы похвастаться PUE менее 1,06.

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

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

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

Информация с жестких дисков периодически копируется на магнитную ленту.

Роботизированная ленточная библиотека в ЦОД Южной Каролины

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

Еще в 2010 году инженеры IBM компании Fujifilm разработали прототип кассетного накопителя, плотность записи которого около 29,5 Гбит на квадратный дюйм, что является мировым рекордом по плотности записи информации на магнитную ленту — на маленький картридж 10x10x2 сантиметров поместится 35 терабайт данных.

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

И такой случай уже был. В 2011 году произошел крупный сбой Gmail. Потерянные письма 40 000 пользователей были восстановлены из ленточных библиотек Oracle StreamLine 8500 с использованием дисков Linear Tape-Open (LTO).

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

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

Google рассматривает свои ЦОД как конкурентное преимущество, поэтому только критически важные сотрудники имеют прямой доступ к серверным стойкам.

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

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

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

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

Четвертый уровень — центр управления безопасностью. Это отдельное защищенное помещение внутри ЦОД, куда «стекается» информация от всех систем защиты на объекте: данные от камер, открытия/закрытия дверей, биометрии. Это «мозг» всей системы безопасности дата-центра.

Пятый уровень — этаж центра обработки данных. Доступ сюда имеет меньше 1% сотрудников ЦОД. Учитывая, что среднее количество персонала на объектах Google — 350 человек — это не более 3-4 сотрудников на весь дата-центр. Это исключительно инженеры и техники, обслуживающие, модернизирующие и ремонтирующие серверное оборудование.

Несмотря на это, хранящиеся данные зашифрованы. В результате те, у кого есть доступ к машинам, не имеют доступа к данным, которые на них находятся.

Шестой уровень — безопасное уничтожение жестких дисков. В отличие от вышедших их строя серверов, которые компания пытается реанимировать или разобрать на компоненты, поломанные жесткие диски полностью уничтожаются. Это общий подход Google по сохранению конфиденциальности данных. Контроль над носителями информации внутри ЦОД — целая цепочка действий, начинающаяся от прибытия дисков с завода на объект, и заканчивающаяся их вывозом на мусоропереработку.

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

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

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

Каждый год уровни безопасности тестируются группой инженеров SRE (Site Reliability Engineering), которые имитируют реальную атаку на дата-центры.

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

Обычно специалисты SRE собираются в конференц-зале одного из ЦОД США, после чего наблюдают за реакцией сотрудников в атакуемых дата-центрах в других частях мира. Менеджеры по ликвидации чрезвычайных ситуаций должны выполнять процедуры реагирования для поддержания работоспособности ЦОД.

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

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

В Финляндии, Дании и Чили расположены три крупные электростанции, питающие местные дата-центры Google.

Чилийская компания AES Chile с помощью ветряных турбин генерирует 125 МВт энергии для дата-центра в муниципалитете Киликура недалеко от Сантьяго.

В Финляндии Google подписал контракт с Ilmatar на покупку примерно 60% от 211 МВт энергии, вырабатываемых крупнейшей ветряной электростанции Финляндии. Ее продукция покрывает потребности ЦОД в Хамине и 36 000 домов поблизости.

В Дании благодаря солнечному проекту Rodby Fjord 150 МВт энергии поставляется в дата-центр Фредерисии.

Строящаяся солнечная электростанция Rodby Fjord

Согласно официальным планам, Google стремится обеспечить 5 ГВт безуглеродной энергии в ключевых производственных регионах к 2030 году — это около 5 миллиардов долларов инвестиций, позволяющих избежать количества выбросов, равного ежегодному вывозу с дорог более 1 миллиона автомобилей.

Google даже разработал отдельный продукт — Environmental Insights Explorer, позволяющий отслеживать выбросы углекислого газа более, чем в 3000 городах по всему миру.

Однако, в 2015 году исследователь Джоана Молл показала, что выбросы сетевой инфраструктуры Google все еще велики — около 500 кг CO2 в секунду. Она основывалась на данных об интернет-трафике за 2015 год, где среднее количество запросов — 47 000 в секунду. Поэтому каждый запрос — приблизительно 0,01 кг CO2. Google никак не оспаривал эти данные, хотя еще в 2009 году он сам публиковал отчет о 0,2 граммах CO2 на каждый запрос.

Что в итоге?

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

Предиктивный взгляд компании на серверные технологии, способы добычи энергии и варианты использования природных ресурсов заканчивается в аккурат в той точке, где обычно начинается дорогостоящее, но не факт, что эффективное решение. Можно сказать, Google следует правилу Парето, не пытаясь ухватиться за дополнительные 20% эффективности, потеряв при этом 80% ресурсов. Google весьма рационален в таких вопросах.

Тем не менее, он определенно задает тренды, которым спустя время следуют и другие участники рынка. В том числе крупные IT-гиганты: Apple, Facebook, Microsoft, Amazon.

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

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

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

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

Используемые в материале изображения были взяты из официальной галереи Google.

---

НЛО прилетело и оставило здесь промокод для читателей нашего блога:

— 15% на все тарифы VDS (кроме тарифа Прогрев) — HABRFIRSTVDS.

Серверы Google / Хабр

BBSoD 19 сентября 2007 в 02:00

IT-компании

Вот список имён серверов Google, использующихся для различных сервисов компании, которые вернулись в HTTP-заголовках. Не всем серверам присвоены очевидные имена, а некоторые из них могут даже показать на интересные данные (например, ctcserver используется для ещё не запущенного сервиса Google Call, на который ссылается robots. txt). Google Web Server — это изменённая версия обычного сервера Apache, запущенного на Linux.

Название сервера	Сервисы, область применения
GWS (Google Web Server)	Поиск по Сети, Поиск изображений и другие сервисы
GFE/1.3 (Google Front-End)	Gmail, Календарь, Альбомы Picasa, Docs, Blogger, orkut, Reader и многие другие сервисы
GWS-GRFE/0.50	Группы
bsfe (Blog Search Front-End)	Поиск по блогам
OFE/0.1 (Ocean Front-End)	Поиск по книгам, Поиск по патентам
SMS search frontend 1.0	Google SMS
Search-History HTTP Server	История поиска
Auto-Completion Server	Google Suggest, авто-дополнение в Firefox/Google Toolbar
TrustRank Frontend	Безопасный веб-сёрфинг
GCS/1. 0	Безопасный веб-сёрфинг
SFE/0.8	Finance
FTS ©1997-2007 Interactive Data Managed Solutions AG	Таблицы Finance
asfe	Base
mediaserver	Base (изображения)
cffe	Поиск товаров (Froogle)
btfe	Эскизы: Поиск по изображениям, Google Video, Youtube
Video Stats Server	Google Video
cachefe:image (Cache Front-End)	Фотографии Picasa
staticfe	Изображения интерфейса (Picasa Web)
ctcserver	Google Call ( www.google.com/call )
GoogleChartServer/1.0	используется для динамически изменяющихся таблиц (вроде статистики Google Video)
NFE/1. 0 (News Front-End)	Новости
mfe (Maps Front-End)	Карты
Keyhole Server 2.4	Maps, Earth (изображения)
PSFE/4.0	Alerts
igfe (iGoogle Front-End)	iGoogle
COMINST/1.0	Инталляционные пакеты (Pack, Picasa)
TWS/0.9 (Translation Web Server)	Переводчик
mws (Music Web Server)	Поиск музыки
R2FE/1.0 (Reviews Front-End)	Обзоры (Музыка, Фильмы)
zfe	Обзоры
pfe	Co-op
codesite/5477219	Code
ga-reporting-fe	Отчёты Analytics
ucfe	Analytics
lpfe	Analytics (www. google-analytics.com/siteopt.js)
Toolbar Gaia User Service Server	Идентификация Google Toolbar
cafe (Ad Conversion Front-End)	Переходы
AdClickServer	Тестовый сервер рекламы Google
Google Trends	Google Trends
TFE/0.0 (Transliteration Front-End)	Перевод в хинди
Apache	большинство сервисов Lab

via Google Operating System

Теги:

• Google
• серверы
• HTTP-заголовки

Хабы:

• IT-компании

Всего голосов 33: ↑30 и ↓3 +27

Просмотры

13K

Комментарии 5

Максим Мельников @BBSoD

Пользователь

Комментарии Комментарии 5

Google Cloud Messaging — Xamarin

• Статья
• 09/21/2022
• Чтение занимает 6 мин

Предупреждение

Google не рекомендуется GCM по состоянию на 10 апреля 2018 года. Следующие документы и примеры проектов больше не поддерживаются. Api сервера и клиента Google GCM будут удалены сразу после 29 мая 2019 г. Google рекомендует перенести приложения GCM в Firebase Cloud Messaging (FCM). Дополнительные сведения о GCM нерекомендуемой и миграции см. в разделе Google Deprecated Cloud Messaging.

Чтобы приступить к использованию Firebase Cloud Messaging с Xamarin, см. раздел Firebase Cloud Messaging.

Google Cloud Messaging (GCM) — это служба, которая упрощает обмен сообщениями между мобильными приложениями и серверными приложениями. В этой статье содержится обзор работы GCM и объясняется, как настроить службы Google, чтобы приложение пользовалось GCM.

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

Обзор

Google Cloud Messaging (GCM) — это служба, которая обрабатывает отправку, маршрутизацию и очередь сообщений между серверными приложениями и мобильными клиентскими приложениями. Клиентское приложение — это приложение с поддержкой GCM, которое выполняется на устройстве. Сервер приложений (предоставленный вами или вашей компанией) — это сервер с поддержкой GCM, с которым ваше клиентское приложение взаимодействует через GCM:

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

Google Cloud Messaging in Action

Когда подчиненные сообщения отправляются с сервера приложений в клиентское приложение, сервер приложений отправляет сообщение на сервер подключения GCM; сервер подключения GCM, в свою очередь, перенаправит сообщение на устройство, на котором выполняется клиентское приложение.

Сообщения можно отправлять по протоколу HTTP или XMPP (расширяемый протокол обмена сообщениями и присутствия). Так как клиентские приложения не всегда подключены или работают, сервер подключения GCM в очереди и сохраняет сообщения, отправляя их в клиентские приложения по мере повторного подключения и становятся доступными. Аналогичным образом, GCM будет отправлять вышестоящие сообщения из клиентского приложения на сервер приложений, если сервер приложений недоступен.

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

• Ключ API — ключ API предоставляет серверу приложений доступ к службам Google; GCM использует этот ключ для проверки подлинности сервера приложений. Прежде чем использовать службу GCM, необходимо сначала получить ключ API из консоли разработчика Google, создав проект. Ключ API должен быть защищен; Дополнительные сведения о защите ключа API см. в рекомендациях по безопасному использованию ключей API.

• Идентификатор отправителя

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

• Токен регистрации — маркер регистрации — это GCM удостоверение клиентского приложения на определенном устройстве. Маркер регистрации создается во время выполнения. Приложение получает маркер регистрации при первой регистрации в GCM во время работы на устройстве. Маркер регистрации разрешает экземпляру клиентского приложения (работающему на этом устройстве) получать сообщения от GCM.

• Идентификатор приложения — удостоверение клиентского приложения (независимо от любого устройства), которое регистрируется для получения сообщений от GCM. В Android идентификатор приложения — это имя пакета, записанное в AndroidManifest.xml, например com.xamarin.gcmexample.

Настройка Google Cloud Messaging (далее в этом руководстве) содержит подробные инструкции по созданию проекта и созданию этих учетных данных.

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

Регистрация с помощью GCM

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

1. Клиентское приложение обращается GCM для получения маркера регистрации, передав идентификатор отправителя в GCM.

2. GCM возвращает маркер регистрации клиентскому приложению.

3. Клиентское приложение перенаправит маркер регистрации на сервер приложений.

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

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

Подчиненные сообщения

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

1. Сервер приложений отправляет сообщение в GCM.

2. Если клиентское устройство недоступно, сервер GCM сохраняет сообщение в очереди для последующей передачи.

3. Когда клиентское устройство доступно, GCM отправляет сообщение клиентскому приложению на этом устройстве.

4. Клиентское приложение получает сообщение от GCM и обрабатывает его соответствующим образом. Например, если сообщение является удаленным уведомлением, оно отображается пользователю.

В этом сценарии обмена сообщениями (где сервер приложений отправляет сообщение в одно клиентское приложение), сообщения могут содержать до 4 КБ.

Подробные сведения (включая примеры кода) о получении подчиненных сообщений GCM в Android см. в разделе «Удаленные уведомления».

Обмен сообщениями в разделах

Обмен сообщениями в разделе — это тип подчиненных сообщений, в которых сервер приложений отправляет одно сообщение нескольким устройствам клиентского приложения, которые подписываются на раздел (например, прогноз погоды). Сообщения тем могут содержать до 2 КБ, а обмен сообщениями в разделах поддерживает до одного миллиона подписок на приложение. Если GCM используется только для обмена сообщениями в разделе, клиентское приложение не требуется для отправки маркера регистрации на сервер приложений.

Групповые сообщения

Групповые сообщения — это тип подчиненных сообщений, в которых сервер приложений отправляет одно сообщение нескольким устройствам клиентского приложения, принадлежащим группе (например, группе устройств, принадлежащих одному пользователю). Длина групповых сообщений может составлять до 2 КБ для iOS устройств и до 4 КБ для Android устройств. Группа ограничена не более чем 20 участниками.

Вышестоящему обмену сообщениями

Если клиентское приложение подключается к серверу, поддерживающему XMPP, оно может отправлять сообщения обратно на сервер приложений, как показано на следующей схеме:

1. Клиентское приложение отправляет сообщение на сервер подключения XMPP GCM.

2. Если сервер приложений отключен, сервер GCM сохраняет сообщение в очереди для последующей пересылки.

3. При повторном подключении сервера приложений GCM перенаправит сообщение на сервер приложений.

4. Сервер приложений анализирует сообщение для проверки удостоверения клиентского приложения, а затем отправляет сообщение «ack» в GCM для подтверждения получения сообщения.

5. Сервер приложений обрабатывает сообщение.

Вышестоящее сообщение Google объясняет, как структурировать сообщения в кодировке JSON и отправлять их на серверы приложений, на которые работает сервер облачных подключений google на основе XMPP.

Настройка Google Cloud Messaging

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

Включение служб Google для приложения

1. Войдите в консоль разработчиков Google с помощью учетной записи Google (т. е. ваш адрес Gmail) и создайте проект. Если у вас есть существующий проект, выберите проект, который требуется включить GCM. В следующем примере создается новый проект с именем XamarinGCM :

2. Затем введите имя пакета для приложения (в этом примере имя пакета — com.xamarin.gcmexample) и нажмите кнопку «Продолжить» для выбора и настройки служб:

   Обратите внимание, что это имя пакета также является идентификатором приложения для приложения.

3. В разделе «Выбор и настройка служб » перечислены службы Google, которые можно добавить в приложение. Щелкните Cloud Messaging:

4. Затем нажмите кнопку «ВКЛЮЧИТЬ GOOGLE CLOUD MESSAGING«:

5. Ключ API сервера и идентификатор отправителя создаются для приложения. Запишите эти значения и нажмите кнопку CLOSE:

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

Просмотр Project Параметры

Параметры проекта можно просмотреть в любое время, войдите в Google Cloud Console и выберите проект. Например, можно просмотреть идентификатор отправителя , выбрав проект в раскрывающемся меню в верхней части страницы (в этом примере проект называется XamarinGCM). Идентификатор отправителя — это номер Project, как показано на этом снимке экрана (идентификатор отправителя здесь 9349932736):

Чтобы просмотреть ключ API, щелкните диспетчер API , а затем щелкните «Учетные данные»:

Дополнительные сведения

• RfC 6120 и RFC 6121 объясняют и определяют расширяемый протокол обмена сообщениями и присутствия (XMPP).

Сводка

В этой статье представлен обзор Google Cloud Messaging (GCM). В нем описаны различные учетные данные, используемые для идентификации и авторизации обмена сообщениями между серверами приложений и клиентскими приложениями. Он иллюстрировал наиболее распространенные сценарии обмена сообщениями, а также подробные инструкции по регистрации приложения с помощью GCM для использования служб GCM.

• Обмен сообщениями в облаке

центров обработки данных – Google

• Анимационный видеосериал, посвященный инновациям в центрах обработки данных

  2022

  Discovering Data Centers – это анимационный видеосериал об инновациях, лежащих в основе центров обработки данных Google. Загляните за кулисы в технологические тонкости, которые обеспечивают работу центров обработки данных Google по всему миру и в больших масштабах, и узнайте, как дизайн, технологии, эксплуатация и устойчивость сочетаются друг с другом, чтобы сделать центры обработки данных такими захватывающими. Смотрите 1 и 2 сезоны здесь.

• Истории из мировой столицы центров обработки данных

  2022

  Компания Google гордится тем, что управляет несколькими центрами обработки данных в Северной Вирджинии — глобальном центре цифровой экономики — и поддерживает местные общественные организации, которые меняют жизнь людей. Познакомьтесь с двумя вдохновляющими местными организациями, Global Inheritance и Mobile Hope, с которыми мы сотрудничаем, чтобы знакомить больше молодых женщин со STEM и бороться с бездомностью среди молодежи.

• Наш экологический отчет

  2021

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

• Подкаст о дата-центрах и людях, которые их заставляют

  2021

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

• Наше обязательство по рациональному использованию водных ресурсов

  2021

  Компания Google берет на себя обязательство по рациональному использованию водных ресурсов, чтобы к 2030 году пополнить запасы воды, превышающей потребление, и поддерживать водную безопасность в сообществах, где мы работаем. Это означает, что Google будет восполнять 120 % потребляемой нами воды в среднем в наших офисах и центрах обработки данных.

• Полный вперед и круглосуточная безуглеродная энергия

  2021

  Мы подключаемся к первому в своем роде геотермальному проекту, который добавит «всегда включенную» чистую энергию в электросеть рядом с нашими центрами обработки данных в Неваде. . Достижения в области экологически чистых технологий, таких как твердая геотермальная энергия, в сочетании с интеллектуальными вычислениями в наших центрах обработки данных помогают нам приблизиться к 24/7 безуглеродной энергии к 2030 году.

• Более чистые центры обработки данных, включая аккумуляторы

  2020

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

• Реализация безуглеродного будущего

  2020

  Мы являемся первой крупной компанией, взявшей на себя обязательство работать на безуглеродной энергии круглосуточно и без выходных во всех наших центрах обработки данных и кампусах по всему миру, и мы работаем над тем, чтобы сделать это к 2030 году. Узнайте у генерального директора Сундара Пичаи о нашем неизменном стремлении стать безуглеродным.

• Внутри центра обработки данных Google

  2020

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

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

• Дата-центры эффективнее, чем когда-либо

  2020

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

• Европейская инфраструктура Google

  2019

  Цифровая трансформация — это определяющая задача и возможность для европейской экономики. Копенгагенская экономика’ 2019исследование подробно описывает усилия Google по поддержке экономики Европы при сохранении энергоэффективности.

• Раскрытие цифровых возможностей в Европе

  2019

  Планы инвестировать 3 миллиарда евро в расширение наших центров обработки данных по всей Европе в течение следующих двух лет доведут наши общие инвестиции в европейскую интернет-инфраструктуру до 15 миллиардов евро с 2007 года. Наши инвестиции стимулируют экономическую активность для региона и поддерживать более 13 000 рабочих мест с полной занятостью в ЕС каждый год.

• Наша самая крупная покупка возобновляемой энергии за всю историю

  2019

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

• 100% возобновляемая энергия, второй год подряд

  2019

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

• Центры обработки данных Google и сообщества

  2018

  В Google мы заботимся о сообществах, в которых работаем и живем. Наши центры обработки данных помогают поддерживать круглосуточную работу Интернета, поддерживая местную экономику и создавая рабочие места. Узнайте об их положительном влиянии в отчете Oxford Economics для США и в отчете Copenhagen Economics для Европы.

• 100% возобновляемая энергия — только начало

  2017

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

• Представляем проект настенной росписи центра обработки данных

  2016

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

• Экскурсия в виртуальной реальности внутри центра обработки данных Google

  2015

  Люди часто спрашивают, что находится внутри центра обработки данных Google. В этом виртуальном туре на 360° (проведенном в Даллесе, штат Орегон) вы можете увидеть, где живет Google Cloud, и многочисленные меры высокой безопасности, которые мы используем для защиты не только данных клиентов, но и нашей собственной индивидуальной инфраструктуры.

• Использование наших данных для повышения эффективности

  2014

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

• Расширение доступа к возобновляемым источникам энергии

  2013

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

• Демонстрация того, из чего мы сделаны — внутри и снаружи

  2012

  Чтобы получить редкий взгляд на то, где мы используем наши продукты, такие как Поиск, YouTube, Gmail, Диск и Фото, просмотрите нашу фотогалерею технологий, людей, и места, где продукты Google работают круглосуточно и без выходных.

• Сертификация наших высоких экологических стандартов

  2011

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

• Использование возобновляемых источников энергии в наших сообществах

  2010

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

• Делимся тем, что узнали

  2009

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

• Стать первой углеродно-нейтральной интернет-компанией

  2007

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

• Проектирование эффективных центров обработки данных

  2003

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

• Новаторские высокоэффективные серверы

  2001

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

ПОДРОБНЕЕ

Узнайте, где расположены наши центры обработки данных

Мы владеем и управляем центрами обработки данных по всему миру, чтобы наши продукты работали 24 часа в сутки, 7 дней в неделю.

ПОСМОТРЕТЬ ВСЕ МЕСТА

Жизнь в центрах обработки данных Google

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

ПОЗНАКОМЬТЕСЬ С УДИВИТЕЛЬНЫМИ ЛЮДЯМИ, РАЗРАБОТЧИВШИМИ ТЕХНОЛОГИИ

Узнайте больше о центрах обработки данных Google

• Безопасность центров обработки данных: шесть уровней

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

• Google Data Center 360° Tour

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

• Познакомьтесь с нашими европейскими соседями

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

• Проект настенной росписи центра обработки данных

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

• Google и экономика замкнутого цикла

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

• Внутри центра обработки данных Google

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

Узнайте, как мы это делаем

Как решить проблему с сервером Google на Android-Carlcare

Ваш телефон сообщает «Проблема связи с серверами Google» при попытке выполнить задачу? Ты не одинок. Большое количество пользователей Android сообщили об одной и той же проблеме на своих устройствах Android. Кажется, это происходит, в частности, при открытии некоторых приложений и сервисов Google.

Проблема с сервером Google иногда может раздражать, особенно когда вам нужно что-то сделать как можно скорее. Тем не менее, это не вечная проблема, и вам не нужно паниковать. Вот комплексные решения, которые можно попробовать, когда на вашем смартфоне возникает проблема с сервером Google.

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

1. Сначала проверьте подключение к Интернету
2. Попробуйте подключиться к другой сети
3. Убедитесь, что дата и время вашего устройства верны
4. Отключить двухэтапную аутентификацию
5. Удалите свой аккаунт Google
6. Очистить информацию и резерв Google Services
7. Повторно добавьте свою учетную запись Google
8. Переустановите сервисы Google Play
9. Обновление файлов хоста (только для рутированных телефонов)

Во-первых, проверьте подключение к Интернету

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

Сделать это довольно просто; все, что вам нужно, это запустить быструю интернет-проверку в другом приложении. Вы можете открыть свой веб-браузер или попробовать отправить текст в WhatsApp, чтобы подтвердить подключение. Если другие приложения также не могут подключиться к сети, вот несколько советов по восстановлению вашей сети:

• Если вы используете мобильную сеть, включите режим полета примерно на 30 секунд. Затем снова выключите его и включите мобильные данные.
• Если вы подключены к сети Wi-Fi, вы можете попробовать перезагрузить маршрутизатор. Затем перезагрузите устройство, чтобы проверить, устранена ли проблема.

 Если проблема с сервером Google возникает снова после того, как проблема связана с Интернетом, попробуйте следующее решение, приведенное ниже.

Попробуйте подключиться к другой сети

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

Вот подробный шаг:

• Переключите телефон на другую сеть (например, на мобильную сеть)
• Как обычно добавьте свою учетную запись Google на устройство.
• Теперь вы можете вернуться к своей предыдущей сети, не сталкиваясь с проблемой сервера Google.

Убедитесь, что ваша дата и время точны

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

Итак, быстрая проверка. Выполните следующие действия, чтобы исправить дату и время на телефоне.

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

Теперь попробуйте снова использовать приложение Google, чтобы посмотреть, решит ли оно проблему. Если нет, начните применять более технические решения ниже.

Невозможность двухэтапной аутентификации

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

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

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

• Откройте настройки
• Найдите и выберите вкладку Google
• Коснитесь Управление учетной записью Google
• На вкладке Security нажмите на двухэтапную проверку
• Вы будете перенаправлены в свой веб-браузер. Войдите в свою учетную запись Google еще раз.
• Коснитесь Отключите , чтобы отключить процесс.

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

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

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

• Откройте устройство Настройки
• Найдите Accounts и откройте его.
• Выберите свой аккаунт Google из списка.
• Затем нажмите УДАЛИТЬ УЧЕТНУЮ ЗАПИСЬ , чтобы выйти. Между тем, вам может потребоваться сначала нажать кнопку с тремя точками в правом верхнем углу, в зависимости от вашей версии Android.
• Просмотрите следующее содержимое, затем нажмите УДАЛИТЬ УЧЕТНУЮ ЗАПИСЬ еще раз, чтобы подтвердить процесс.

Очистить информацию и резерв служб Google

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

• Запустите приложение Settings на своем телефоне.
• Нажмите Приложения и уведомления (или Приложения)
• Коснитесь «Просмотреть все приложения» или «Управление приложениями» , если вы еще не видите свой список приложений.
• В правом верхнем углу нажмите кнопку с тремя точками и нажмите Показать систему.
• Теперь найдите Google Account Manager в списке приложений и откройте его.
  • Затем нажмите Хранилище и кэш.
  • Выберите, Очистить кэш, затем нажмите Очистить данные.
• Выполните те же действия, чтобы очистить кэш и данные для Сервисов Google Play, Google Services Framework, Google One Time Init и Google Play Store.

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

Повторно добавьте свою учетную запись Google

После завершения перезагрузки телефона вернитесь на страницу Учетные записи на своем устройстве, чтобы снова добавить свою учетную запись Google. Вы больше не должны видеть ошибку «Произошла проблема при обмене данными с серверами Google 2020» . Вот как:

• Еще раз запустите ваше устройство Настройки
• Нажмите на учетные записи
• Нажмите Добавить учетную запись и выберите Google из вариантов.
• Возможно, вам потребуется подтвердить свой пароль, а затем ввести данные своей учетной записи на следующем экране.

Вы больше не должны сталкиваться с проблемой неработающего сервера Google. Однако попробуйте следующее решение, если проблема не устранена.

Переустановите службы Google Play

Если проблема не устранена, вам следует переустановить Службы Google Play , выполнив следующие действия.

• Запустите приложение Settings на своем телефоне
• Нажмите Приложения и уведомления
• Нажмите Управление приложениями или Просмотреть все приложения или Информация о приложении, , если вы не видите свои приложения сразу,
• Теперь откройте Службы Google Play в списке.
• Затем нажмите кнопку с тремя точками в правом верхнем углу.
• Нажмите Удалить обновления!
• Тем не менее, на странице прокрутите вниз и коснитесь Сведения о приложении. Это приведет вас в магазин Google Play.
• Оттуда нажмите Обновить , чтобы установить последнюю версию приложения Службы Google Play.
• Наконец, перезагрузите телефон после установки обновления, чтобы обновить систему.

Обновить файлы хоста (только для телефонов с root-правами)

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

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

• Сначала удалите свой аккаунт Google.
• Загрузите ES File Explorer онлайн и установите его.
• Запустите приложение и предоставьте необходимые разрешения.
• Откройте боковое меню и включите Root Explorer.
• Разрешить корневой запрос Super User , если будет предложено. (Это не сработает, если ваш телефон не рутирован!)
• После этого нажмите Local, , затем выберите Device из накопителей
• Оттуда коснитесь папки « System» и откройте оттуда папку «etc» .
• Найдите и щелкните файл «Hosts» внутри папки.
• Выберите Редактор заметок ES из списка.
• Теперь внутри редактора очистите существующие тексты из файла hosts и вставьте следующее:
  • 0.0.1 локальный хост
• Наконец, сохраните файл и закройте редактор.
• Теперь вы можете снова войти в свою учетную запись Google.

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

Аналогичным образом, если ваше устройство сообщает, что возникла проблема со связью с серверами Google на YouTube, вы можете сбросить настройки приложения или надстройки, используемой для входа в приложение YouTube Vanced, например Vanced micro-G 9.0007

Firebase Cloud Messaging

Серверная часть Firebase Cloud Messaging состоит из двух компонентов:

• Серверная часть FCM , предоставленная Google.
• Ваш сервер приложений или другая среда доверенных серверов , где логика вашего сервера работает, например, облачные функции для Firebase или другие облачные среды. управляется Google.

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

Требования к среде доверенного сервера

Среда вашего сервера приложений должна соответствовать следующим критериям:

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

Выбор варианта сервера

Вам необходимо выбрать способ взаимодействия с серверами FCM: либо с помощью Firebase Admin SDK или необработанные протоколы. Благодаря поддержке популярных языков программирования и удобным методам для для обработки аутентификации и авторизации рекомендуется использовать Firebase Admin SDK.

Варианты взаимодействия с серверами FCM включают следующее:

• Firebase Admin SDK, который поддерживает Узел, Ява, питон, С#, а также Идти.
• FCM HTTP v1 API, который является самой современной из опций протокола, с более безопасной авторизацией и гибкими кросс-платформенные возможности обмена сообщениями (SDK Firebase Admin основан на этом протоколе и обладает всеми присущими ему преимуществами). Поскольку новые функции обычно добавляются в HTTP v1 Только API, мы рекомендуем использовать этот API для большинства случаев использования.
• устаревший HTTP-протокол. Новым проектам настоятельно рекомендуется использовать HTTP API FCM v1. вместо устаревшего протокола.
• устаревший серверный протокол XMPP. Новым проектам настоятельно рекомендуется использовать FCM v1 HTTP. API вместо устаревшего протокола.

Firebase Admin SDK для FCM

API администратора FCM обрабатывает аутентификацию с помощью серверной части и облегчает отправку сообщения и управление подписками на темы. С Firebase Admin SDK вы можете:

• Отправка сообщений на отдельные устройства
• Отправка сообщений в темы и операторы условий, соответствующие одной или нескольким темам.
• Подписка и отписка устройств от тем
• Создание полезной нагрузки сообщений с учетом различных целевых платформ

SDK Admin Node.js предоставляет способы отправки сообщений группам устройств.

Чтобы настроить Firebase Admin SDK, см. раздел Добавление Firebase Admin SDK на ваш сервер. Если у вас уже есть проект Firebase, начните с Добавить SDK. Также не забудьте включить Cloud Messagin API в Страница настроек облачного обмена сообщениями для вашего проекта. Затем, после установки Firebase Admin SDK, вы можете начать писать логику для создавать запросы на отправку.

Firebase Admin SDK предоставляет API для подписка и отписка устройств от тем FCM. Эти операции могут подписывать или отменять подписку на регистрацию до 1000 устройств. жетоны за раз. Для получения дополнительной информации см. Управление темами с сервера.

Серверные протоколы FCM

В настоящее время FCM предоставляет следующие необработанные серверные протоколы:

• API FCM HTTP v1
• Наследие HTTP-протокол
• Устаревший протокол XMPP

Ваш сервер приложений может использовать эти протоколы по отдельности или в тандеме. Потому что это самая современная и самая гибкая для отправки сообщений на несколько платформ, По возможности рекомендуется использовать FCM HTTP v1 API. Если ваши требования включить восходящий обмен сообщениями с устройств на сервер, вам потребуется реализовать протокол XMPP.

Обмен сообщениями XMPP отличается от обмена сообщениями HTTP следующим образом:

• Сообщения восходящего/нисходящего потока
  • HTTP: только нисходящий поток, от облака к устройству.
  • XMPP: восходящий и нисходящий (от устройства к облаку, от облака к устройству).
• Обмен сообщениями (синхронный или асинхронный)
  • HTTP: синхронно. Серверы приложений отправляют сообщения в виде запросов HTTP POST и дождитесь ответа. Этот механизм является синхронным и блокирует отправителя от отправки другое сообщение, пока не будет получен ответ.
  • XMPP: асинхронный. Серверы приложений отправляют/получают сообщения всем своим устройств на полной скорости линии через постоянные соединения XMPP. Сервер соединений XMPP отправляет подтверждения или уведомления об ошибках (в форме специальных сообщений XMPP ACK и NACK, закодированных в формате JSON) асинхронно.
• JSON
  • HTTP: сообщения JSON отправляются как HTTP POST.
  • XMPP: сообщения JSON, инкапсулированные в сообщения XMPP.
• Обычный текст
  • HTTP: обычные текстовые сообщения, отправленные как HTTP POST.
  • XMPP: не поддерживается.
• Многоадресная рассылка в нисходящем направлении на несколько маркеров регистрации.
  • HTTP: поддерживается в формате сообщения JSON.
  • XMPP: не поддерживается.

Реализация протокола HTTP-сервера

Чтобы отправить сообщение, сервер приложений отправляет запрос POST с заголовок HTTP и тело HTTP, состоящее из пар ключ-значение JSON. Дополнительные сведения о параметрах заголовка и тела см. Создание запросов на отправку сервера приложений

Реализация протокола сервера XMPP

Полезная нагрузка JSON для сообщений FCM аналогична протокол HTTP, с этими исключения:

• Несколько получателей не поддерживаются.
• FCM добавляет обязательное поле message_id . Этот идентификатор уникально идентифицирует сообщение в соединении XMPP. ACK или NACK от FCM использует message_id для идентификации сообщения, отправленного с серверов приложений в FCM. Поэтому важно, чтобы этот message_id был не только уникальным (по идентификатор отправителя), но всегда присутствует.
• XMPP использует ключ сервера для авторизации постоянного подключения к FCM. Дополнительные сведения см. в разделе Авторизация запросов на отправку.

В дополнение к обычным сообщениям FCM отправляются управляющие сообщения, обозначенные поле message_type в объекте JSON. Значение может быть либо ‘ack’ или ‘nack’ или ‘control’ (см. форматы ниже). Любое сообщение FCM с unknown message_type может игнорироваться вашим сервером.

Для каждого сообщения устройства, которое ваш сервер приложений получает от FCM, ему необходимо отправить сообщение ACK. Ему никогда не нужно посылать сообщение NACK. Если вы не отправляете ACK для сообщения, FCM повторно отправляет его при следующем установлении нового соединения XMPP, если только сообщение истекает первым.

FCM также отправляет ACK или NACK для каждого сообщения от сервера к устройству. Если вы этого не сделаете получить либо, это означает, что соединение TCP было закрыто в середине операция, и ваш сервер должен повторно отправить сообщения. Видеть Управление потоком для получения подробной информации.

См. Справочник по протоколу для списка всех сообщений параметры.

Формат запроса

Сообщение с полезной нагрузкой — сообщение уведомления

Вот строфа XMPP для сообщения уведомления:

<сообщение>
  
  {
     "to":"REGISTRATION_ID", // "to" заменяет "registration_ids"
     "уведомление": {
        "title": "Португалия против Дании",
        «тело»: «5 к 1»
      },
      "time_to_live":"600"
  }
  

 

Сообщение с полезной нагрузкой — сообщение данных

Вот строфа XMPP, содержащая сообщение JSON от сервера приложений к FCM:

 <сообщение>
  
  {
      "to":"REGISTRATION_ID", // "to" заменяет "registration_ids"
      "message_id":"m-1366082849205" // новое обязательное поле
      "данные":
      {
          "Привет, мир",
      }
      "time_to_live":"600",
  }
  

 

Формат ответа

Ответ FCM может иметь три возможных формы. Первый — обычный ‘ack’ сообщение. Но когда ответ содержит ошибку, есть 2 сообщения могут принимать различные формы, описанные ниже.

Сообщение ACK

Вот строфа XMPP, содержащая сообщение ACK/NACK от FCM к серверу приложений:

 <сообщение>
  
  {
      "от": "РЕГИД",
      "message_id":"m-1366082849205"
      "тип_сообщения":"подтверждение"
  }
  

 

Сообщение NACK

Ошибка NACK — это обычное сообщение XMPP, в котором message_type статус сообщение «nack». Сообщение NACK содержит:

• Код ошибки NACK.
• Описание ошибки NACK.

Ниже приведены некоторые примеры.

Плохая регистрация:

 <сообщение>
  
  {
    "message_type":"нек",
    "message_id":"msgId1",
    "from":"SomeInvalidRegistrationToken",
    "ошибка": "ПЛОХАЯ_РЕГИСТРАЦИЯ",
    "error_description":"Недопустимый токен в поле "Кому": SomeInvalidRegistrationId"
  }
  
 

Неверный JSON:

 <сообщение>
 
 {
   "message_type":"нек",
   "message_id":"msgId1",
   "from":"bk3RNwTe3H0:CI2k_HHwgIpoDKCIZvvDMExUdFQ3P1. ..",
   "ошибка": "INVALID_JSON",
   "error_description":"InvalidJson: JSON_TYPE_ERROR: Поле \"time_to_live\" должно быть JSON java.lang.Number: abc"
 }
 

 

Превышение скорости передачи сообщений устройства:

 <сообщение>
  
  {
    "message_type":"нек",
    "message_id":"msgId1",
    "от": "РЕГИД",
    "ошибка": "DEVICE_MESSAGE_RATE_EXCEEDED",
    "error_description": "Превышена скорость передачи сообщений в нисходящем направлении для этого регистрационного идентификатора"
  }
  

 

Полный список серверов см. в Справочнике по серверам. Коды ошибок NACK. Если иначе указано, сообщение NACK не следует повторять. Неожиданные коды ошибок NACK следует рассматривать так же, как ВНУТРЕННЯЯ_ОШИБКА_СЕРВЕРА .

Ошибка строфы

В некоторых случаях вы также можете получить ошибку строфы. Ошибка строфы содержит:

• Код ошибки строфы.
• Описание ошибки строфы (свободный текст).

Например:

 
  
     {"случайный": "текст"}
  
  <код ошибки="400" тип="изменить">
    
    
      InvalidJson: JSON_PARSING_ERROR: отсутствует обязательное поле: message_id\n
    
  

 

Управляющие сообщения

Периодически FCM необходимо закрывать соединение для выполнения балансировки нагрузки. Перед этим закрывает соединение, FCM отправляет сообщение CONNECTION_DRAINING , чтобы указать, что соединение сбрасывается и скоро будет закрыт. «Слив» означает прекращение потока сообщений, поступающих в соединение, но позволяет продолжить работу того, что уже находится в конвейере. Когда вы получаете сообщение CONNECTION_DRAINING , вы должны немедленно начать отправлять сообщения другому FCM соединение, открывая новое соединение при необходимости. Тем не менее, вы должны сохранить оригинал открыть соединение и продолжать получать сообщения, которые могут приходить через соединение (и Подтверждение их) — FCM инициирует закрытие соединения, когда оно будет готово.

Сообщение CONNECTION_DRAINING выглядит следующим образом:

 <сообщение>
  
  {
    "message_type":"управление"
    "control_type":"CONNECTION_DRAINING"
  }
  
 

CONNECTION_DRAINING в настоящее время является единственным поддерживаемым control_type .

Управление потоком

Каждое сообщение, отправленное в FCM, получает ответ ACK или NACK.