NCC: Konfiguraationhallinnan parannukset - Kysymys ja vastaus [Nebula 19.10]

Julkaisussa 19.10 Nebula Control Center (NCC) esitteli tärkeitä parannuksia kokoonpanojen synkronointiin. Aiemmin ylläpitäjillä oli käytössään vain sivuston laajuinen asetusten synkronointivaihtoehto, joka kopioi yleiset parametrit eri sivustojen välillä. Tämä vaihtoehto poistettiin 19.10:ssä, ja painopiste siirtyi tiettyjen kohteiden tarkempaan synkronointiin: Porttiprofiilit, PoE-aikataulut ja SSID-tunnukset.

Tämä muutos on merkittävä, koska se antaa ylläpitäjille enemmän hallintaa. Sen sijaan, että he kopioisivat kaikki asetukset, he voivat nyt valita vain sen, mikä on heidän ympäristönsä kannalta tärkeää. Esimerkiksi useita pieniä toimistoja hallinnoiva MSP voi työntää standardoituja SSID-tunnuksia, mutta säilyttää yksilölliset VLAN- tai palomuurikäytännöt.

Tulevaisuutta ajatellen Zyxel on myös ilmoittanut, että suunnitellussa versiossa (19.20) koko toimipaikan laajuinen asetusten synkronointi otetaan uudelleen käyttöön uudelleen suunnitellulla tavalla, joka mahdollistaa yksittäisten AP:iden, kytkimien tai palomuurien valinnan "kaikki tai ei mitään" -lähestymistavan sijaan.

Kysymys 2: Voinko synkronoida porttiprofiileja ja PoE-aikatauluja eri sivustojen välillä?

A2:
Kyllä, tämä on yksi suurimmista parannuksista. Järjestelmänvalvojat voivat nyt valita porttiprofiilit ja PoE-aikataulut toimipaikkojen välisen synkronoinnin aikana. Tämä tarkoittaa sitä, että kytkinporttien vakiomääritykset (kuten VLAN-määritykset, trunk-/yhteystila tai suojausasetukset) voidaan kopioida nopeasti useisiin toimipisteisiin.

Käyttäytyminen on suoraviivaista:

• Jos kohdesivustolla ei ole samannimistä profiilia, NCC luo automaattisesti uuden profiilin.

• Jos samanniminen profiili on jo olemassa, NCC korvaa sen lähdeversiolla.

Tämä varmistaa johdonmukaisuuden, mutta tarkoittaa myös sitä, että ylläpitäjien on oltava varovaisia: jos paikallisia mukautuksia on olemassa samalla nimellä, ne menetetään. Paras käytäntö on käyttää selkeitä nimeämiskäytäntöjä (esim. "HQ-VoIP-profiili") vahingossa tapahtuvien ylikirjoitusten välttämiseksi.

Kysymys 3: Entä jos lähdesivuston porttiprofiili käyttää PoE-aikataulua?

A3:
Tämä tilanne on yleinen todellisissa käyttöönotoissa, esimerkiksi silloin, kun toimistopuhelinten porttiprofiili käyttää aikataulua, joka sammuttaa ne työajan ulkopuolella.

NCC käsittelee tämän riippuvuuden automaattisesti:

• Jos porttiprofiili viittaa PoE-aikatauluun, myös tämä aikataulu synkronoidaan.

• Jos aikataulu on jo olemassa kohdesivustossa, se ylikirjoitetaan.

• Jos sitä ei ole, se luodaan.

Tämä rakenne varmistaa, että porttiprofiilit eivät koskaan "rikkoudu" synkronoinnin jälkeen. Ilman tätä ominaisuutta ylläpitäjien olisi pitänyt luoda aikataulut manuaalisesti uudelleen ennen profiilien kopiointia, mikä oli virhealtista ja aikaa vievää.

Kysymys 4: Onko PoE-aikatauluilla rajoituksia?

A4:
Kyllä, ja tämä on kriittinen seikka, joka ylläpitäjien on ymmärrettävä. NCC itsessään ei rajoita luotavien aikataulujen määrää, mutta laitteisto rajoittaa. Zyxel-kytkimet tukevat enintään viittä PoE-aikataulua laitetta kohden.

Jos synkronointi työntäisi kuudennen aikataulun kytkimelle, synkronointi estyy. Virhe ilmoitetaan NCC:ssä, jotta ylläpitäjä tietää, miksi synkronointi epäonnistui.

Käytännön esimerkki: Jos kohteessa on jo viisi paikallisesti määritettyä aikataulua ja synkronoit porttiprofiilin, joka viittaa uuteen aikatauluun, NCC estää synkronoinnin. Ylläpitäjän on joko poistettava käyttämättömät aikataulut tai yhdistettävä ne.

Kysymys 5: Muuttuuko porttiprofiilien tai PoE-aikataulujen synkronointi välittömästi kytkimen asetuksia?

A5:
Ei - ja tämä ero on tärkeä. Synkronointi vain siirtää profiilit kohdesivuston konfigurointitietokantaan. Jotta muutokset tulisivat voimaan, järjestelmänvalvojan on määritettävä porttiprofiili tai PoE-aikataulu tiettyyn kytkinporttiin.

Tämä on suunniteltu tarkoituksella antamaan ylläpitäjille enemmän hallintaa. Kuvittele, että synkronoit uuden "IP-kameraprofiilin", jossa on korkea PoE-teho ja VLAN 30. Et ehkä halua, että kaikki toimipisteet soveltavat sitä heti - mutta kun se on käytettävissä kohdesivustossa, paikalliset ylläpitäjät voivat soveltaa sitä valikoivasti tarpeen mukaan.

K6: Miten SSID-synkronointi on parantunut?

A6:
Ennen tätä parannusta SSID-synkronointi oli "kaikki tai ei mitään": ylläpitäjien oli kopioitava kaikki SSID-profiilit sivustosta toiseen, vaikka he tarvitsivat vain yhtä tai kahta. Tämä aiheutti usein ristiriitoja ja tarpeettomia määrityksiä.

Nyt NCC mahdollistaa valikoivan SSID-synkronoinnin. Ylläpitäjä voi valita synkronoitavat SSID-profiilit (esim. "CorpWiFi" ja "Guest"). NCC tekee sen automaattisesti:

• Lisää puuttuvat lähtöpaikat kohdesivustossa.

• Täyttää tyhjät paikat oletusarvoilla.

Tämä helpottaa huomattavasti usean toimipaikan hallintaa. Esimerkiksi 10 sivukonttoria hallinnoiva MSP voi työntää vain vakiomuotoisen "Guest WiFi" SSID-tunnuksen ja jättää "Local Staff WiFi" SSID-tunnuksen erilaiseksi jokaisessa toimipisteessä.

K7: Onko SSID-synkronoinnissa rajoituksia?

A7:
Kyllä, on olemassa useita tärkeitä rajoituksia:

1. AP-ryhmittely - Jos lähde- tai kohdesivusto käyttää AP-ryhmittelyä, SSID-synkronointia ei tueta.

2. Tunnisteet - SSID-tunnisteita ei synkronoida. Ylläpitäjien on luotava ne uudelleen manuaalisesti kohdesivustossa.

3. Microsoft Entra ID -kirjautuminen - Jos lähdesivusto käyttää tätä todennusmenetelmää, se poistetaan käytöstä kohdesivustossa synkronoinnin jälkeen. Tämä johtuu siitä, että Entra ID -metatiedot ovat sivustokohtaisia, eikä niitä voi kopioida.

Nämä rajoitukset on tärkeää muistaa, kun suunnitellaan laajamittaisia SSID-käyttöönottoja eri sivustojen välillä.

K8: Mitä tapahtuu, jos synkronointi aloitetaan jo käynnissä olevassa sivustossa?

A8:
Kun NCC aloittaa synkronoinnin, sivusto merkitään "käynnissä olevaksi synkronoinniksi " . Jos toinen ylläpitäjä yrittää aloittaa uuden synkronoinnin samalle sivustolle tämän prosessin aikana, pyyntö jätetään huomiotta ja näytetään virheilmoitus.

Tämä mekanismi estää ristiriitoja ja suojaa tietojen eheyttä. Ilman sitä samanaikaiset synkronoinnit voisivat johtaa vioittuneisiin tai epäjohdonmukaisiin profiileihin sivustojen välillä.

K9: Miten voin tarkistaa, onnistuiko synkronointi?

A9:
Kun prosessi on päättynyt, NCC päivittää ilmoituskellon tuloksen. Jos synkronointi onnistui, se vahvistetaan siinä. Jos se epäonnistui, viestissä ilmoitetaan syy - esimerkiksi:

• Kytkimen 5 aikataulun rajan ylitys.

• Ryhmittelystä johtuvatSSID-ristiriidat.

• Ei tuetut asetukset, kuten Entra ID -todennus.

Tämä palautesilmukka on ratkaisevan tärkeä vianmäärityksen kannalta. Ylläpitäjien tulisi aina tarkistaa ilmoitukset synkronoinnin jälkeen varmistaakseen, että kaikki on sovellettu tarkoituksenmukaisesti.

Yhteenveto

NCC 19.10:n konfiguraationhallinnan parannukset antavat ylläpitäjille paljon enemmän joustavuutta ja hallintaa. Koko sivuston laajuisten asetusten synkronoinnin sijaan he voivat nyt valita tarkalleen, mitkä profiilit ja aikataulut jaetaan eri sivustojen kesken. Tämä vähentää virheitä, parantaa tehokkuutta ja tukee nykyaikaisia MSP-työnkulkuja.

Muutokset ovat erityisen hyödyllisiä organisaatioille, jotka hallinnoivat useita sivukonttoreita, joissa ydinpalveluiden (esim. SSID-tunnukset, VLAN:t, PoE-käytännöt) yhdenmukaisuus on tärkeää, mutta myös toimipaikkakohtaiset vaihtelut on säilytettävä.

Tulevaisuutta ajatellen Zyxel on ilmoittanut, että suunnitellussa 19.20-julkaisussa koko toimipaikan laajuinen synkronointi palaa uudistetussa muodossa, mikä mahdollistaa entistä hienojakoisemman hallinnan AP-, kytkin- ja palomuurikonfiguraatioille.