По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Существует новая тенденция для стандартов проектирования топологии сети - создание быстрой, предсказуемой, масштабируемой и эффективной коммуникационной архитектуры в среде центра обработки данных. Речь идет о топологии Leaf-Spine, о которой мы поговорим в этой статье.
Почему Leaf-Spine?
Учитывая повышенный фокус на массовые передачи данных и мгновенные перемещения данных в сети, стареющие трехуровневые конструкции в центрах обработки данных заменяются так называемым дизайном Leaf-Spine. Архитектура Leaf-Spine адаптируется к постоянно меняющимся потребностям компаний в отраслях big data с развивающимися центрами обработки данных.
Другая модель
Традиционная трехуровневая модель была разработана для использования в общих сетях. Архитектура состоит из Core маршрутизаторов, Aggregation маршрутизаторов (иногда этот уровень называется Distribution) и Access коммутаторов. Эти устройства взаимосвязаны путями для резервирования, которые могут создавать петли в сети. Частью дизайна является протокол Spanning Tree (STP) , предотвращающий петли, однако в этом случае деактивируется все, кроме основного маршрута и резервный путь используется только тогда, когда основной маршрут испытывает перебои в работе.
Введение новой модели
С конфигурацией Leaf-Spine все устройства имеют точно такое же количество сегментов и имеют предсказуемую и согласованную задержку информации. Это возможно из-за новой конструкции топологии, которая имеет только два слоя: слой «Leaf» и «Spine». Слой Leaf состоит из access коммутаторов, которые подключаются к таким устройствам как сервера, фаерволы, балансировщики нагрузки и пограничные маршрутизаторы. Уровень Spine, который состоит из коммутаторов, выполняющих маршрутизацию, является основой сети, где каждый коммутатор Leaf взаимосвязан с каждым коммутатором Spine.
Чтобы обеспечить предсказуемое расстояние между устройствами в этом двухуровневом дизайне, динамическая маршрутизация уровня 3 используется для соединения уровней. Она позволяет определить наилучший маршрут и настроить его с учетом изменения сети. Этот тип сети предназначен для архитектур центров обработки данных, ориентированных на сетевой трафик типа «Восток-Запад» (East-West). Такой трафик содержит данные, предназначенные для перемещения внутри самого центра обработки данных, а не наружу в другую сеть. Этот новый подход является решением внутренних ограничений Spanning Tree с возможностью использования других сетевых протоколов и методологий для достижения динамической сети.
Преимущества Leaf-Spine
В Leaf-Spine сеть использует маршрутизацию 3го уровня. Все маршруты сконфигурированы в активном состоянии с использованием протокола равноудаленных маршрутов Equal-Cost Multipathing (ECMP) . Это позволяет использовать все соединения одновременно, сохраняя при этом стабильность и избегая циклов в сети. При использовании традиционных протоколов коммутации уровня 2, таких как Spanning Tree в трехуровневых сетях, он должен быть настроен на всех устройствах правильно, и все допущения, которые использует протокол Spanning Tree Protocol (STP), должны быть приняты во внимание (одна из простых ошибок, когда конфигурация STP связана с неправильным назначением приоритетов устройства, что может привести к неэффективной настройке пути). Удаление STP между уровнями Access и Aggregation приводит к гораздо более стабильной среде.
Другим преимуществом является простота добавления дополнительного оборудования и емкости. Когда происходит ситуация перегрузки линков, которая называется oversubscription (что означает, что генерируется больше трафика, чем может быть агрегировано на активный линк за один раз) возможность расширять пропускную способность проста - может быть добавлен дополнительный Spine коммутатор и входящие линии могут быть расширены на каждый Leaf коммутатор, что приведет к добавлению полосы пропускания между уровнями и уменьшению перегрузки. Когда емкость порта устройства становится проблемой, можно добавить новый Leaf коммутатор. Простота расширения оптимизирует процесс ИТ-отдела по масштабированию сети без изменения или прерывания работы протоколов коммутации уровня 2.
Недостатки Leaf-Spine
Однако этот подход имеет свои недостатки. Самый заметный из них – увеличение количества проводов в этой схеме, из-за соединения каждого Leaf и Spine устройства. А при увеличении новых коммутаторов на обоих уровнях эта проблема будет расти. Из-за этого нужно тщательно планировать физическое расположение устройств.
Другим основным недостатком является использование маршрутизации уровня 3.Ее использование не дает возможность развертывать VLAN’ы в сети. В сети Leaf-Spine они локализованы на каждом коммутаторе отдельно – VLAN на Leaf сегменте недоступен другим Leaf устройствам. Это может создать проблемы мобильности гостевой виртуальной машины в центре обработки данных.
Применение Leaf-Spine
Веб-приложения со статичным расположением сервера получат преимущество от реализации Leaf-Spine. Использование маршрутизации уровня 3 между уровнями архитектуры не препятствует приложениям веб-масштаба, поскольку они не требуют мобильности сервера. Удаление протокола Spanning Tree Protocol приводит к более стабильной и надежной работе сети потоков трафика East-West. Также улучшена масштабируемость архитектуры. Корпоративные приложения, использующие мобильные виртуальные машины (например, vMotion), создают проблему, когда сервер нуждается в обслуживании внутри центра обработки данных, из-за маршрутизации уровня 3 и отсутствие VLAN. Чтобы обойти эту проблему, можно использовать такое решение, как Software Defined Networking (SDN) , которое создает виртуальный уровень 2 поверх сети Leaf-Spine. Это позволяет серверам беспрепятственно перемещаться внутри центра обработки данных.
Другие решения
В качестве альтернативы маршрутизации уровня 3 топология Leaf-and-Spine может использовать другие протоколы, такие как Transparent Interconnection of Lots of Links (TRILL) или Shortest Path Bridging (SPB) для достижения аналогичной функциональности. Это достигается за счет сокращения использования Spanning Tree и включения ECMP уровня 2, а также поддержки развертывания VLAN между Leaf коммутаторами.
Итог
Сети Leaf-Spine предлагают множество уникальных преимуществ по сравнению с традиционной трехуровневой моделью. Использование маршрутизации 3-го уровня с использованием ECMP улучшает общую доступную пропускную способность, используя все доступные линии. Благодаря легко адаптируемым конфигурациям и дизайну, Leaf-Spine улучшает управление масштабируемостью и контролем над перегрузкой линий. Устранение протокола Spanning Tree Protocol приводит к значительному повышению стабильности сети. Используя новые инструменты и имея способность преодолевать присущие ограничения другими решениям, такими как SDN, среды Leaf-Spine позволяют ИТ-отделам и центрам обработки данных процветать при удовлетворении всех потребностей и потребностей бизнеса.
Почти каждому проекту необходимо так или иначе взаимодействовать с внешним миром. Если вы работаете со средами JavaScript, то, вероятнее всего, для этой цели вы будете использовать Fetch API.
Но задумайтесь, когда вы работаете с API, помните ли вы синтаксические конструкции наизусть или вам все-таки нужны небольшие подсказки?
Я написал большое количество статей о JavaScript и о вещах, с ним связанных. И я сделал это только для того, чтобы потом я мог частенько (заново) посещать их, чтобы освежить свою память или позаимствовать какой-нибудь пример кода, который, как я помню, «где-то был».
В этой статье я постараюсь создать еще один примерно подобный ресурс. Я перечислю 9 самых распространенных запросов Fetch API.
Я уверен, что вы их использовали, и далеко не раз. Но было бы прекрасно не искать в старых проектах синтаксическую конструкцию того конкретного запроса, что вы использовали полгода назад?
?
Для чего нужен Fetch API?
Нас уже успели избаловать всеми службами, которые предоставляют хорошие SDK, которые абстрагируются от реальных запросов API. Мы просто запрашиваем данные с помощью обычных языковых конструкций, и даже не задумываемся о самом процессе обмена данными.
Но что, если у платформы, которую мы выбрали, нет SDK? Или что, если вы создаете как сервер, так и клиента? В таких случаях вам нужно будет обрабатывать запросы самостоятельно. И вот как это можно сделать с помощью Fetch API.
Простой запрос GET с помощью Fetch API
fetch('{url}')
.then(response => console.log(response));
Простой запрос POST с помощью Fetch API
fetch('{url}', {
method: 'post'
})
.then(response => console.log(response));
Запрос GET с маркером авторизации (токеном на предъявителя) в Fetch API
fetch('{url}', {
headers: {
'Authorization': 'Basic {token}'
}
})
.then(response => console.log(response));
Запрос GET с данными строки запроса в Fetch API
fetch('{url}?var1=value1&var2=value2')
.then(response => console.log(response));
Запрос GET с CORS в Fetch API
fetch('{url}', {
mode: 'cors'
})
.then(response => console.log(response));
Запрос POST с маркером авторизации и данными строки запроса в Fetch API
fetch('{url}?var1=value1&var2=value2', {
method: 'post',
headers: {
'Authorization': 'Bearer {token}'
}
})
.then(response => console.log(response));
Запрос POST с данными формы в Fetch API
let formData = new FormData();
formData.append('field1', 'value1');
formData.append('field2', 'value2');
fetch('{url}', {
method: 'post',
body: formData
})
.then(response => console.log(response));
Запрос POST с данными JSON в Fetch API
fetch('{url}', {
method: 'post',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
'field1': 'value1',
'field2': 'value2'
})
})
.then(response => console.log(response));
Запрос POST с данными JSON и CORS в Fetch API
fetch('{url}', {
method: 'post',
mode: 'cors',
headers: {
'Content-Type': 'application/json'
},
body: JSON.stringify({
'field1': 'value1',
'field2': 'value2'
})
})
.then(response => console.log(response));
Как обработать результат запроса Fetch API
Fetch API возвращает
Promise
(промис). Именно поэтому я всегда использую
.then()
и функцию обратного вызова для того, чтобы обработать ответ:
fetch(...).then(response => {
// process the response
}
Но, если находитесь в асинхронной функции, вы можете просто дождаться результата:
async function getData(){
let data = await fetch(...);
// process the response
}
А теперь давайте посмотрим на то, как мы можем извлечь данные из полученного ответа.
Как проверить код состояния ответа Fetch API
Когда мы отправляем запросы POST, PATCH и PUT, чаще всего нас интересует возвращаемый код состояния:
fetch(...)
.then(response => {
if (response.status == 200){
// all OK
} else {
console.log(response.statusText);
}
});
Как получить обычное число из ответа Fetch API
Некоторые конечные точки API могут отправлять обратно идентификатор новой записи базы данных, которая была создана с помощью ваших же данных:
var userId;
fetch(...)
.then(response => response.text())
.then(id => {
userId = id;
console.log(userId)
});
Как конвертировать данные JSON из ответа Fetch API
Чаще всего в теле ответа вы получаете данные JSON:
var dataObj;
fetch(...)
.then(response => response.json())
.then(data => {
dataObj = data;
console.log(dataObj)
});
Помните о том, что вы сможете получить доступ к этим данным только после того, как разрешите оба промиса. Иногда это может создавать путаницу, поэтому я больше предпочитаю использовать асинхронные методы и дожидаться результатов:
async function getData(){
var dataObj;
const response = await fetch(...);
const data = await response.json();
dataObj = data;
console.log(dataObj);
}
Заключение
Эти примеры должны прикрыть вас в большинстве ситуаций.
Рутовая учетная запись – это, как мы все знаем, специальная учетная запись пользователя в Linux, которая имеет доступ ко всем файлам, всем командам и которая может делать практически все-все-все на сервере Linux. В этой статье мы расскажем, как легко изменить пароль root в CentOS 8.
Если вам нужно восстановить утерянный или забытый пароль в CentOS, то воспользуйтесь этой статьей.
Подготовка
Чтобы изменить пароль root в CentOS 8, вам необходимо иметь права sudo или иметь действительный пароль учетной записи root.
Тут можно прочитать про то как дать sudo права новому пользователю, а тут про то как дать права sudo уже существующему.
Выполните в командной строке sudo –l:
$ sudo –l
User may run the following commands on host-centos:
(ALL : ALL) ALL
Если вы видите такой вывод, то это значит, что вы сможете сменить рутовый пароль.
Если вы устанавливали CentOS 8 с настройками по умолчанию, то возможно, вы решили заблокировать учетную запись root по умолчанию. Обратите внимание, что изменение пароля root разблокирует учетку.
Изменить пароль пользователя root с помощью passwd
Самый простой способ изменить пароль root в CentOS 8 - это выполнить команду passwd и указать новый пароль.
$ sudo passwd
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Для выбора устойчивого пароля воспользуйтесь нашим генератором паролей
Чтобы подключиться от имени пользователя root в CentOS 8, используйте команду «su» без аргументов.
$ su -
Password:
[root@localhost ~]#
Изменить пароль пользователя root с помощью su
В другом случае, если вы не имеете права sudo, вы все равно можете изменить пароль root, если у вас есть текущий рутовый пароль.
Сначала подключаемся как рут:
$ su -
Password:
root@host-centos:~#
Теперь, когда вы подключены как root, просто запустите команду «passwd» без каких-либо аргументов.
$ passwd
Changing password for user root.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
Теперь вы можете выйти из рутовой учетки, нажав «Ctrl + D», вы будете перенаправлены на ваш основной пользовательский аккаунт.
Вот и все, это очень просто!