Automounter - Automounter

En automounter er ethvert program eller programvare som automatisk monterer filsystemer som svar på tilgangsoperasjoner fra brukerprogrammer. Et automounter systemverktøy ( demon under Unix ), når det blir varslet om fil- og katalogtilgangsforsøk under selektivt overvåkede underkatalogstrær, gjør dynamisk og gjennomsiktig lokale eller eksterne enheter tilgjengelige.

Automounter har til formål å bevare lokale systemressurser og å redusere koblingen mellom systemer som deler filsystemer med et antall servere. For eksempel kan en stor til mellomstor organisasjon ha hundrevis av filservere og tusenvis av arbeidsstasjoner eller andre noder som når som helst får tilgang til filer fra et hvilket som helst antall av disse serverne. Vanligvis vil bare et relativt lite antall eksterne filsystemer ( eksport ) være aktive på en hvilken som helst node til enhver tid. Hvis du utsetter monteringen av et slikt filsystem til en prosess faktisk trenger tilgang til det, reduseres behovet for å spore slike monteringer, noe som øker påliteligheten, fleksibiliteten og ytelsen.

Ofte vil en eller flere filservere være utilgjengelige (ned for vedlikehold, på et eksternt og midlertidig frakoblet nettverk, eller tilgang til via en overbelastet lenke). Administratorer finner det ofte også nødvendig å flytte data fra en filserver til en annen - for å løse kapasitetsproblemer og balansere belastningen. Å ha datamonteringspunkter automatisert gjør det lettere å konfigurere klientsystemer i slike tilfeller.

Disse faktorene utgjør sammen utfordringer for eldre "statiske" administrasjonsmetoder for filsystemmonteringstabeller ( fstabfilene på Unix-systemer). Automounter-verktøy løser disse utfordringene og lar sysadmins konsolidere og sentralisere tilknytningen av monteringspunkter (katalognavn) til eksporten. Når det er gjort riktig, kan brukerne få tilgang til filer og kataloger på en transparent måte som om alle arbeidsstasjonene og andre noder knytter seg til et enkelt filsystem for hele virksomheten.

Man kan også bruke automounters til å definere flere arkiver for skrivebeskyttet data; klientsystemer kan automatisk velge hvilket lager som skal monteres basert på tilgjengelighet, belastning på filserver eller nærhet til nettverket.

Hjemmekataloger

Mange virksomheter vil ha et antall filservere som er vert for hjemmekatalogene til forskjellige brukere. Alle arbeidsstasjoner og andre noder som er interne for slike organisasjoner (vanligvis alle som står bak en felles brannmur som skiller dem fra Internett ) vil bli konfigurert med automounter-tjenester slik at enhver bruker som logger på en hvilken som helst node implisitt utløser tilgang til sin egen hjemmekatalog som følgelig , er montert på et felles monteringspunkt, for eksempel . Dette tillater brukere å få tilgang til sine egne filer fra hvor som helst i bedriften, noe som er svært nyttig i UNIX-miljøer, hvor brukerne kan ofte påberope kommandoer på mange eksterne systemer via ulike jobb-utsending kommandoer som , , eller , eller via X11 eller VNC protokoller. /home/usersshtelnetrshrlogin

/nett

En veldig vanlig standard automounter lokal bane er av skjemaet hvor er vertsnavnet til den eksterne maskinen og er banen som eksporteres over NFS på den eksterne maskinen. Denne notasjonen frigjør generelt systemadministratoren fra å måtte administrere hver eksporterte bane eksplisitt via et sentralt automounter-kart. /net/hostname/nfspathhostnamenfspath

Programvareandeler og arkiver

I noen databehandlingsmiljøer er ikke arbeidsstasjoner og datanoder vert for installasjoner av hele programvaren som brukere kanskje vil ha tilgang til. Systemer kan "avbildes" med et minimalt eller typisk tverrsnitt av den mest brukte programvaren. I noen miljøer kan brukere også kreve spesialisert eller sporadisk tilgang til eldre versjoner av programvare (for eksempel kan utviklere trenge å utføre feilrettinger og regresjonstesting, eller noen brukere kan trenge tilgang til arkiverte data ved hjelp av utdaterte verktøy).

Vanligvis vil organisasjoner tilby lagringssteder eller "depoter" av slik programvare, klar for installasjon etter behov. Disse kan også omfatte fullstendige kopier av systembildene som maskiner har operativsystemene sine opprinnelig installert fra, eller er tilgjengelige for reparasjon av systemfiler som kan bli ødelagt i løpet av maskinens livssyklus.

Noen programvare kan kreve ganske betydelig lagringsplass eller kan være i rask (kanskje intern) utvikling. I slike tilfeller kan programvaren installeres på og konfigureres til å kjøres direkte fra filserverne.

Dynamisk variantautomater

I det enkleste tilfellet inneholder en filserver data og kanskje skripter som er tilgjengelige for ethvert system i et miljø. Imidlertid kan visse typer filer (kjørbare binærfiler og delte biblioteker, spesielt) bare brukes av bestemte typer maskinvare eller spesifikke versjoner av spesifikke operativsystemer.

I situasjoner som dette støtter automounter-verktøy generelt noen måter å "kartlegge" eller "interpolere" variable data i monteringsargumentene.

For eksempel, en organisasjon med en blanding av Linux og Solaris kan systemer sørge for å være vert for sine programvarepakke repositories for hver på en felles fil-server ved hjelp av eksport navn som depot:/export/linuxog depot:/export/solarishhv. Deretter kan de ha kataloger for hver av OS-versjonene de støtter. Ved å bruke de dynamiske variasjonsfunksjonene i biltelleren deres, kan de konfigurere alle systemene sine slik at enhver administrator på en hvilken som helst maskin i bedriften kan få tilgang til tilgjengelige programvareoppdateringer under /software/updates. En bruker på et Solaris-system vil finne de Solaris-kompilerte pakkene under /software, mens en Linux- bruker vil finne RPM , DEB eller andre pakker for deres spesifikke OS-versjon derunder. Videre vil en Solaris-bruker på en SPARC- arbeidsstasjon ha sin /software/updateskartlagt til en passende eksport for systemets arkitektur, mens en Solaris-bruker på en x86- PC gjennomsiktig vil finne /software/updateskatalogen hans som inneholder pakker som passer for systemet hans. Noe programvare (skrevet på skriptspråk som Perl eller Python ) kan installeres og / eller kjøres på hvilken som helst støttet plattform uten portering, rekompilering eller ompakking av noe slag. En systemadministrator kan tenkes å finne slik programvare i en /software/commoneksport.

I noen tilfeller kan organisasjoner også bruke regionale eller stedsbaserte variable / dynamiske kartlegginger - slik at brukere i en bygning eller et område blir dirigert til en nærmere filserver som er vert for replikasjoner av ressursene som er vert andre steder.

I alle disse tilfellene tillater automounter-verktøy brukerne å få tilgang til filer og kataloger uten hensyn til den faktiske fysiske plasseringen. Ved hjelp av en automounter kan brukerne og systemadministratorene vanligvis få tilgang til filer der de "skal" være og finne ut at de ser ut til å være der.

Programvare

Tom Lyon utviklet den originale programvaren for automatisk montering på Sun Microsystems : SunOS 4.0 gjorde tilgjengelig automatisk montering i 1988. Sun Microsystems ga til slutt lisensiering av denne implementeringen til andre kommersielle UNIX-distribusjoner. Solaris 2.0, først utgitt i 1992, implementerte biltelleren med et pseudofilesystem kalt autofs, som kommuniserer med en brukermodemon som utfører montering. Andre Unix-lignende systemer har tatt i bruk implementeringen av automounteren - inkludert AIX , HP-UX og Mac OS X 10.5 og nyere.

I desember 1989 ga Jan-Simon Pendry ut Amd , en automounter "basert i ånd" på SunOS automount-programmet. Amd har også blitt kjent som Berkeley Automounter .

Linux har en uavhengig implementering av en autofs-basert automounter; versjon 5 av denne biltjeneren fungerer generelt sett kompatibelt med Solaris-telleren.

FreeBSD brukes til å levere Amd ; Fra og med 10.1 har den en ny bilteller som ligner på Solaris. Den har deretter blitt portet til DragonFly BSD og NetBSD .

Noen operativsystemer støtter også automatisk montering av eksterne stasjoner (for eksempel diskstasjoner eller flash-stasjoner som bruker FireWire- eller USB- tilkoblinger) og flyttbare medier (for eksempel CDer og DVDer ). Denne teknologien skiller seg fra bilmonteringen som er beskrevet her; det innebærer montering av lokale medier når brukeren fester dem til eller setter dem inn i systemet, i stedet for å montere kataloger fra eksterne filservere når det henvises til dem. Linux bruker for øyeblikket (fra og med Linux 2.6) bruker-plass-programmet udev til denne formen for automatisk montering. Noen automatiseringsfunksjoner er implementert i det separate programmet HAL , men fra og med 2010 blir de slått sammen til udev. OpenBSD har hotplugd (8) som utløser spesielle skript på feste eller løsne av flyttbare enheter, slik at brukeren enkelt kan legge til montering av flyttbare stasjoner. I macOS diskarbitrationdutfører denne formen for automatisk montering. I FreeBSD kan det flyttbare mediet håndteres av automounter, akkurat som nettverksandeler er.

Ulemper og forbehold

Selv om automounter-verktøy (og eksterne filsystemer generelt) kan gi sentralt administrert, konsistent og stort sett gjennomsiktig tilgang til organisasjonens lagringstjenester, kan de også ha sine ulemper:

  • Tilgang til automatiserte kataloger kan utløse forsinkelser mens automounter løser kartleggingen og monterer eksporten på plass.
  • Tidsavbrudd kan føre til demontering av monterte kataloger (hvilken situasjon kan senere føre til forsinkelser i monteringen ved neste forsøk på tilgang).
  • Kartleggingen av monteringspunkt for å eksportere argumenter gjøres vanligvis via noen katalogtjenester som LDAP eller NIS , som utgjør en annen avhengighet (potensielt feilpunkt).
  • Når noen systemer krever hyppig tilgang til noen ressurser, mens andre bare trenger sporadisk tilgang, kan dette føre til vanskelige eller umulige problemer med å implementere en konsistent, virksomhetsomfattende blanding av lokalt "speilet" (replikerte) og automatiserte kataloger.
  • Når data overføres fra en filserver (eksport) til en annen, kan det være et ubestemt antall systemer som av forskjellige grunner fremdeles har en aktiv montering på den gamle plasseringen ("foreldede NFS- monteringer"); disse kan forårsake problemer som til og med kan kreve omstart av ellers perfekt stabile verter.
  • Organisasjoner kan oppdage at de har laget en "spaghetti" av kartlegginger som kan medføre betydelig administrasjonsomkostninger og noen ganger ganske forvirring blant brukere og administratorer.
  • Brukere kan bli så vant til gjennomsiktigheten av automatiserte ressurser at de forsømmer å vurdere noen av forskjellene i tilgangssemantikk som kan gjelde for nettverksfiler, sammenlignet med lokalt monterte enheter. Spesielt kan programmerere forsøke å bruke "låsing" -teknikker som er trygge og gir de ønskede atomicitetsgarantiene på lokale filsystemer, men som er dokumentert som iboende sårbare for løpsforhold når de brukes på NFS.

Referanser